这个功能很实用，算是解决了一个被讨论了数年的痛点：能否给worker自身加一个前置缓存。
以前每次提及这个问题，cf的回答总是架构不支持，设计不兼容等等，没想到突然支持了这个功能。
故事是怎样的
cf的作为CDN，请求命中边缘缓存时是直接返回给用户，不回源到服务器
在没有Workers Cache前，如果你使用了worker，作为网站的中间件，那么请求将会变成下图所示
用户流量首先到达worker，然后worker再拉取边缘缓存，也就是说，缓存永远要在worker后执行
这样有什么问题
- 对于一些静态资源（如图片、css等），总是需要先触发一次worker的执行
- 对于一些由worker动态生成的 不随时间改变的内容，无法利用缓存优势
所以，开发者经常问cf能否在worker前再加一道缓存，但cf的回答永远是no，两层缓存太复杂了，流程上会很麻烦，而且要考虑很多针对Zone（域名）的配置和针对worker的缓存的冲突等等。
但cf一直在努力，为了解决这种浪费serverless配额的现象，cf推出了多个功能
静态资源最开始的解决方案是pages，pages优先储存静态资源，然后允许增加function来解决动态资源
同时，cf还尝试了js runtime内的cache api来解决worker动态缓存的问题
但pages静态资源优先不够灵活，与各种SSR的现代方案相性不好，不太适合未来的趋势
因此cf在去年大刀阔斧把worker扩充，在动态优先的worker上支援静态资源能力，这创建了一个worker的旁路，让静态资源不触发worker执行
但是问题仍然存在，对于一些直接构建为worker应用的网站，没有回源，并且有些资源是动态生成的，需要缓存的。
比如一个构建到worker上的CMS应用，用户创建文章，文章会被预渲染储存到d1数据库，文章路径按照之前的功能模式是无法缓存到CF的边缘网络上的（一般来说是这样）。这意味着对于无回源应用，用户只能吃到浏览器缓存，而非CDN的边缘缓存。
在此之前这种情况几乎是无解，只能让cf worker执行然后返回资源。
现在有了Workers Cache，下图的数据流得以实现
允许流量到达cf worker前先走缓存，完全无worker调用。而且缓存是由前一次（未缓存）请求worker时动态构建的，简洁优雅。
这块拼图补上后，cf worker的短板终于减少一大块，无回源的纯粹的worker应用在内容网站上的能力是大大延申了，这对近年来的cf worker blog/cms项目是不错的功能。
Frameworks like Astro, TanStack Start, Next.js, Remix, and SvelteKit all ship a Cloudflare adapter that builds your app as a Worker
看cf blog里面提到驱动cf实现这个功能的主要原因，是现代前端框架允许把应用直接编译成cf worker（尤其是SSR应用），因此问题更加突出了。
估计这跟astro/vite等主流前端团队纷纷加入到cf也有关系，甚至在框架里面直接提供了一等支持🤣
有啥用
开发者估计会觉得很实用，普通用户的话🤔好像感受不会很明显
能想到的一些场景不算多，比如：某些搞cf 图床的，没有回源到服务器而是调用第三方储存，可以额外加个worker前缓存减少CPU消耗；其他的一些纯粹放到cf上的应用可以尝试下？
注意
Cache hits don't run your Worker, and they don't bill CPU time. They do count as a request at the standard Workers request rate, the same as any other invocation.
虽然不消耗CPU时间，但还是计算请求次数，对于付费用户可以缩减费用，但对于免费用户，每日的请求数配额量没有改善。（刀法精准）
其他
cf worker对于普通用户来说，更多是部署一些个人的项目，或者辅助用途。直接作为生产方案还是较少，有个原因是太怕被刷了，没有达量限制不敢放心付费用🤣
不知道cf能否增加一个额外worker前置鉴权中间层，利用js代码做鉴权判断，不允许返回，只能调用next()来请求后面的worker，类似于某种削弱版的snippets。
随手杂记，行文匆匆，如果谬误欢迎指出
看了一下 虽然缓存了 但也要计算请求数
看不明白🤦♂️