Worker 终于有了自己的缓存,但旧文档还没跟上这个故事

Cloudflare 这次的更新说起来很简单:配置文件里加一行 cache: { enabled: true },再配上早就熟悉的 Cache-Control 响应头,一个跑在 Worker 前面的缓存就开起来了。命中了,Worker 不执行,CPU 不计费;没命中,Worker 跑一次,把结果存起来,下一个请求直接读缓存。

思路很顺,但翻一下 Cloudflare 自己现存的文档会发现别扭的地方:官方白纸黑字写着,旧的 Worker 缓存 API 不支持 stale-while-revalidate,跟 Tiered Cache 不兼容,也没有能在代码里调用的按标签清除接口。这三件事,恰好是这次发布拿出来当卖点的三样东西。

Worker 从中间件变成源站,旧缓存框架就跟着失灵

2017 年 Worker 刚出来时,角色是中间件:挡在源站和缓存前面,加个头、改个 URL、做个分流,内容本身还是别处来的。这几年 Astro、Next.js、Remix、SvelteKit 这批框架陆续把 Cloudflare 适配器做成了标配,Worker 背后已经没有别的源站了——它自己就是要渲染页面的那个服务端。

老话说"名不正则言不顺",这次至少把 Worker 的身份叫对了:它已经是源站,缓存自然要挪到它前面,而不是继续挡在它和一个根本不存在的上游之间。每次请求都重新渲染哪怕内容完全没变,这是旧架构在新用法下最大的浪费,也是这次发布真正要解决的问题。

新旧两套 API,到底是不是一回事

问题在于,Cloudflare 现存文档里对旧的 caches.default 接口写得很清楚:不支持后台刷新,不兼容分层缓存,清除缓存只能走控制台或外部 purge 接口,运行时里没有对应调用。这次发布把这三条全部翻了过来。

这不一定是矛盾,更可能是两套系统:Workers Cache 大概率是绕开旧 API 限制重建的新东西,而不是给老接口换了层皮。但对已经在用 caches.default、或者已经配好 Cache Rules 和 Tiered Cache 的企业客户来说,这两种可能性对应完全不同的迁移动作——文档要是没跟上,踩坑的人先跳。

缓存命中不计费,这笔账要看使用场景

对 SSR 框架的开发者来说,这次真正戳中的是账单。Worker 免费计划每请求 CPU 时间上限很低,付费计划上限拉长到分钟级,还有按月的 CPU 毫秒配额,超出部分按量计费。

如果缓存命中真的能让 Worker 完全不跑,这几个数字对高流量、页面重复率高的站点意义很大——之前缓存挡在源站前,Worker 该跑还是得跑,账照付。这一次是第一次让"命中不计费"这句话有了实打实的账单支撑。

缓存命中时 Worker 不跑,这笔账才第一次真正划算。

但清除缓存本身也不是没有约束。按 Tag、Prefix、Hostname 清除在所有计划都能用,速率上限却分得很开:

• 提醒.单次调用最多清除 30 个前缀,Cache-Tag 头总大小上限约 16KB,内容更新频繁的免费计划用户很容易撞到限速。

另外一个容易踩的坑是缓存键本身:workers.dev 子域默认把查询字符串算进缓存键,自定义域名对静态资源默认会忽略查询字符串。同一套代码,换个域名部署,缓存命中率可能完全不一样,这一点迁移前最好先确认清楚。

放进 Vercel、Netlify、Fastly 的坐标系里

行业里,Fastly Compute 在原生缓存失效上一直被认为最稳,但配置门槛也最高;Vercel 的 ISR 跟框架深度绑定,省心但控制粒度有限;Netlify Edge Functions 默认不缓存,得显式加头才开启。

如果 Workers Cache 真能做到宣传里的"一行配置+标准 HTTP 头+代码内按标签清除",它大概率是这四家里可编程性和上手门槛平衡得最好的一个——前提是新旧 API 的边界尽快讲清楚,企业客户的迁移成本才算得出来。

这才是这次发布真正的分水岭:不是缓存本身有多新,而是 Cloudflare 愿不愿意尽快把文档和产品对齐。技术上,Worker 变成源站已经是既成事实;账目上,新旧系统还欠读者一个说法。