这个功能确实补上了 Worker 生态里非常重要的一块。 我们最近也在做类似能力，最大的感受就是，真正难的其实不是「前置缓存」本身，而是如何处理缓存一致性、失效策略以及与动态应用之间的关系。 以前 Worker 的执行链路决定了所有请求都会先进入 Worker，再决定是否命中缓存，这对于传统 CDN 场景没有太大问题，但对于现在越来越多直接编译成 Worker 的 SSR 应用来说，确实会带来额外的计算开销。 如果能把缓存提升到 Worker 前面，同时又允许 Worker 在首次请求时动态生成并写入缓存，就能把「静态资源 + 动态生成但不频繁变化的数据」统一起来，这对 CMS、Blog、文档站、API Cache 等场景都会有比较明显的收益。 我们目前也在开发类似方向，不过除了前置缓存外，还比较关注几个点： 缓存 Key 的自定义能力（Header、Cookie、Query 等参与计算） 标签（Tag）或前缀批量失效 Stale-While-Revalidate（后台刷新） 与 SSR / ISR 等现代框架的协同 多区域缓存一致性和主动预热 我觉得未来 CDN 的缓存能力会越来越偏向「应用层缓存」，而不仅仅是传统的文件缓存，这应该也是近几年边缘计算的发展方向。
@xshell #1 发布于2026/7/8 05:43:05 cloudflare是真的在为用户省钱，它明明可以不用出这个功能让用户花更多的钱 @NodeSeeks #2 发布于2026/7/8 06:12:53 @xshell #1 发布于2026/7/8 05:43:05 cloudflare是真的在为用户省钱，它明明可以不用出这个功能让用户花更多的钱 目前 Cloudflare Workers Cache 已经向所有订阅计划的开发者提供
这个功能确实补上了 Worker 生态里非常重要的一块。
我们最近也在做类似能力，最大的感受就是，真正难的其实不是「前置缓存」本身，而是如何处理缓存一致性、失效策略以及与动态应用之间的关系。
以前 Worker 的执行链路决定了所有请求都会先进入 Worker，再决定是否命中缓存，这对于传统 CDN 场景没有太大问题，但对于现在越来越多直接编译成 Worker 的 SSR 应用来说，确实会带来额外的计算开销。
如果能把缓存提升到 Worker 前面，同时又允许 Worker 在首次请求时动态生成并写入缓存，就能把「静态资源 + 动态生成但不频繁变化的数据」统一起来，这对 CMS、Blog、文档站、API Cache 等场景都会有比较明显的收益。
我们目前也在开发类似方向，不过除了前置缓存外，还比较关注几个点：
我觉得未来 CDN 的缓存能力会越来越偏向「应用层缓存」，而不仅仅是传统的文件缓存，这应该也是近几年边缘计算的发展方向。
@xshell #8
是的，这里感觉可以不计的，没太理解，可能有其他原因
对于普通的free套餐，优势会变弱
update:
我补充到文章里吧，这个挺重要的。