终于搞定！Cloudflare Workers 加上“前置缓存”，Serverless 部署成本大降

最近 Cloudflare 悄悄上线了一个名为 Workers Cache 的新功能，乍一看可能觉得平平无奇，但如果你是重度 Serverless 用户，或者在 Workers 上跑着自己的博客、图床，这绝对算得上是一个“史诗级”的更新。

为什么这么说？因为它解决了一个被开发者吐槽了好几 几年的痛点：能不能给 Worker 这个“中间商”自己也加个前置缓存？

以前：Worker 是必须要经过的“收费站”

在 Cloudflare 的传统架构里，CDN 的边缘缓存是直接给用户返回数据的，不经过源站。但是，一旦你在这个链条里加上了 Workers（用来做鉴权、改写响应或者业务逻辑），数据流向就变了：

用户请求 -> 边缘节点 -> 触发 Worker 执行 -> Worker 去拉取缓存/数据 -> 返回给用户

看明白了吗？以前，哪怕这个请求是一个静态的图片或者 CSS 文件，甚至是一篇已经渲染好的 HTML 文章，只要你的域名绑定了 Worker，每次请求都得先让 Worker 跑一遍。

这就带来了两个大麻烦：

1. 费钱：Workers 是按请求次数计 CPU 时间的，明明是个静态资源，你却要扣我的 Serverless 配额，这不合理。
2. 费时：多了一层 JS 代码的执行环节，延迟自然就上去了。
3. 无回源应用无法缓存：如果是那种没有源服务器、纯粹跑在 Worker + D1 (SQLite) 上的 CMS 博客，以前的内容几乎是无法利用 Cloudflare 边缘缓存优势的，只能每次都现查数据库现渲染。

新架构：Cache 跑到 Worker 前面，优先命中缓存，未命中才执行 Worker

现在：Cache 终于跑到了 Worker 前面

Workers Cache 上线后，这个逻辑终于闭环了。现在的数据流变成了：

用户请求 -> (先查缓存) -> 命中则直接返回 -> 未命中才执行 Worker

最关键的一点是，这个缓存是“动态构建”的。也就是说，第一次请求时 Worker 会执行处理，然后将结果存入缓存；后续的相同请求，连 Worker 的代码都不用跑，直接由边缘节点吐出数据。这对于那些内容生成一次就不变的文章页面、API 响应来说，简直是救命稻草。

为什么现在是好时机？

其实 Cloudflare 以前也有过类似的尝试，比如推 Cloudflare Pages（静态资源优先）或者在 Worker 内部用 Cache API。但 Pages 那种静态优先的模式，和现在流行的 SSR（服务端渲染） 框架有点“水土不服”。

现在，像 Next.js、Astro、Remix、SvelteKit 这些现代前端框架，官方都提供了直接把应用编译成 Worker 的适配器（Adapter）。这意味着越来越多的全栈应用直接变成了 Worker 代码。如果这时候缓存层还跟不上，那体验肯定是崩的。所以 Cloudflare 这次的补丁，也是为了顺应这股“全栈上云端”的潮流。

实战：这东西对我有啥用？

对于普通用户可能感知不强，但对于开发者和技术博主，这几个场景特别香：

• Worker 图床/文件站：很多人的图床逻辑是“用户 -> Worker (鉴权/转存) -> S3/R2”。以前每张图片每次显示都要跑一次 Worker 代码，现在加上 Workers Cache，图片读请求基本 0 成本打到边缘节点，不仅能大幅节省 Worker 的 CPU 配额，还能显著降低 R2 的请求次数（如果 Worker 内部做了逻辑缓存的话）。
• Serverless 博客/CMS：直接用 D1 或者 KV 储存内容的全站 Worker 应用，现在可以愉快地利用 CDN 缓存了。文章发出去后，全世界的读者访问的都是边缘缓存的 HTML，既快又稳。
• API 甚至动态内容：如果你的 API 数据在一定时间内（比如 5 分钟）是不变的，以前只能自己写代码存 KV，现在直接利用 HTTP 缓存头控制即可，省去了不少造轮子的功夫。

一点小期待

这个功能补上后，Cloudflare Workers 作为“独立服务器”替代方案的能力又强了一大截。不过，大家在生产环境使用时还是要注意流量防护（毕竟没有硬性的带宽达量限制，被刷会很肉疼）。

最后，如果未来 CF 能再提供一个“Workers 前置鉴权中间层”，允许用 JS 代码做简单的拦截判断（比如只放行白名单 IP，直接 Reject 掉恶意流量而不消耗 Worker 计算资源），那对于个人开发者来说就真的是完美了。

总的来说，这次更新虽然 quiet，但含金量极高，建议大家有空去翻翻官方文档，把自己的项目优化起来！