Cloudflare 上线 Workers Cache，架构哲学翻转

Cloudflare 上线 Workers Cache https://blog.cloudflare.com/workers-cache

Workers Cache 是位于 Worker 前面的分层缓存。当 Worker 已经成为"源站"本身时，CDN 缓存就应该像对待传统源站一样，挡在 Worker 前面吃流量，让 Worker 不必每次都跑。

这是 Cloudflare 架构哲学的一次翻转。2017 年 Workers 诞生时定位是"在缓存和源站前面做请求变换"——加 header、改 URL、A/B 测试。但近两年 Astro / TanStack Start / Next.js / Remix / SvelteKit 都把 Worker 编译成"服务器本身"，Worker 即 origin。

此时旧架构的痛点暴露：每个请求都得跑代码，哪怕响应字节级相同。性能够快≠免费——既付延迟，也付 CPU 时间。

Workers Cache 给出了"第三条路"（区别于 SSG 与纯 SSR）： · 按需 server-render，把渲染结果缓存起来，TTL 到期再重渲染； · 借助 stale-while-revalidate，连重渲染那一次都不让用户等； · 拿到静态站的速度，又拿到 SSR 的新鲜度，无需框架级 ISR 机制。

五个关键设计 1. 归属 Worker 而非 Zone：一个 Worker 一份缓存，跨 hostname / service binding / workers. dev / 预览 / 多租户共享或隔离；purge 只清当前 entrypoint 2. 默认两层 Tiered Cache：下层在每个 PoP，上层全网聚合；双 miss 才跑 Worker，无需任何配置 3. ctx.props 进 cache key：网关鉴权后把 userId 塞进 props 调后端 cached Worker，按用户天然隔离——把"鉴权"与"按用户缓存"从对立变组合 4. 缓存位于每个 entrypoint 之间：自评"最大解锁"：一个 Worker 可写成 entrypoint 链，每段独立开/关缓存、独立 TTL 与 tag，缓存成为程序的一层而非外挂 5. 标准 HTTP 行为：Vary 按 RFC 9110/9111 全量实现；stale-while-revalidate 三段窗口（fresh / stale 后台刷新 / 窗口外才等）

计费要点 · HIT：只收请求费，免 CPU 时间；MISS/BYPASS 正常计费；无独立 SKU、无存储费。 · 隐藏成本：开启缓存后，原本免费的静态资产与 worker→worker 调用会按标准请求率计费（因为每次都要查缓存）。

当前限制 · Smart Placement 与上层缓存分别选址，全 miss 可能跨数据中心两次； · 响应大小临时统一按 Free 档 512 MB； · 框架集成仅 Astro 落地，Next.js / TanStack Start 在路上； · ctx.cache.invalidate()（标为过期而非硬删）待出。