Cloudflare推出Workers Cache功能，允许在Worker前设置分层缓存。只需一行配置即可启用，缓存命中时直接返回结果，不运行Worker也不消耗CPU；未命中时Worker运行，响应可被缓存供全球后续请求使用。

好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节，并删减了与主题无关的推广性内容。

---

标题：Workers Cache：为你的Worker配备专属缓存

Cloudflare 正式推出 Workers Cache，这是一个位于你的 Worker 之前的分层缓存。只需在 Wrangler 配置中添加一行代码，并使用你熟悉的 Cache-Control 标头即可启用。

启用后，每个可缓存的请求会先命中 Cloudflare 的缓存。如果缓存中有新鲜的响应，Cloudflare 会直接返回，你的 Worker 不会运行，也不会产生 CPU 计费。如果缓存未命中，Worker 会运行，并且如果响应是可缓存的，Cloudflare 会将其存储起来，供后续请求使用。来自全球任何地方的后续请求都可以直接从缓存中获取。

配置非常简单，只需在 wrangler.jsonc 中添加一个代码块：

json { "name": "my-worker", "main": "src/index.ts", "compatibility_date": "2026-05-01", "cache": { "enabled": true } }

之后，你通过设置 HTTP 响应头来控制缓存行为：

javascript return new Response(body, { headers: { "Cache-Control": "public, max-age=300, stale-while-revalidate=3600", "Cache-Tag": "products,product:123", }, });

当内容变更时，你的 Worker 可以清除自己的缓存：

await ctx.cache.purge({ tags: ["product:123"] });

这就是完整的 API。无需配置区域、规则引擎或单独的资源。Worker 的代码就是配置界面，缓存会跟随 Worker 运行，无论是在自定义域名、workers.dev、服务绑定、预览环境还是 Workers for Platforms 中。一个 Worker，一个缓存，一次配置。

为什么服务端渲染应用需要前置缓存

当 Workers 最初推出时，它位于缓存和源服务器之前，用于转换请求。但如今，Workers 本身已成为源服务器。框架（如 Astro、Next.js、Remix 等）将你的应用构建为 Worker，背后没有源服务器。在这种情况下，原始架构没有东西可以缓存，每个请求都会运行你的代码。

Workers Cache 翻转了架构，让 Cloudflare 的缓存位于 Worker 之前。缓存命中时，Worker 完全不运行，CPU 计费为零。缓存未命中时，Worker 运行一次并填充缓存，后续请求从缓存提供。

这解决了服务端渲染的痛点。你不再需要在“构建时预渲染所有内容”和“每次请求都渲染页面”之间做选择。Workers Cache 提供了第三种选择：按需服务端渲染，缓存渲染结果，并在你设定的 TTL 后刷新。你获得了静态站点的速度，同时避免了构建时间，也获得了服务端渲染的新鲜度，而无需承担每次请求都渲染的成本。

stale-while-revalidate 是关键

stale-while-revalidate 指令允许 Cloudflare 在缓存过期后，立即提供过期的副本，同时在后台刷新响应。没有它，缓存过期后的第一个请求必须等待 Worker 重新渲染页面。有了它，这个请求也能立即获得缓存速度的响应。

• 新鲜窗口 (max-age)：Cloudflare 提供缓存响应，Worker 不运行。
• 过期窗口 (stale-while-revalidate)：Cloudflare 提供缓存响应，Worker 在后台运行以刷新它，用户无需等待。
• 超出两个窗口：Cloudflare 运行 Worker 生成新响应，用户需要等待这一次渲染。

Vary 支持内容协商

Workers Cache 支持标准的 HTTP Vary 标头。当你的 Worker 返回带有 Vary: Accept 等标头的响应时，Cloudflare 会为每个不同的标头组合存储一个单独的缓存变体，并只返回与传入请求匹配的变体。这解决了同一 URL 返回不同内容（如 WebP 与 JPEG 图片）时的缓存问题。

这是 Worker 的缓存，而非区域的缓存

Workers Cache 属于 Worker 本身，而不是某个区域。这意味着： - 无需管理区域级别的缓存配置（如 Cache Rules、Page Rules）。 - 缓存跟随 Worker，而非主机名。一个 Worker 绑定到多个域名，或通过服务绑定调用，都共享同一个缓存。 - 缓存可以在 workers.dev、预览 URL 和 Workers for Platforms 中工作。 - 清除操作（Purge）仅限于该 Worker 入口点的缓存，不会影响区域的其他内容。

默认分层缓存

Workers Cache 默认启用区域分层缓存。它包含两层： - 下层：位于离用户最近的 Cloudflare 数据中心。 - 上层：聚合整个网络的缓存填充。

请求先命中下层。如果未命中，下层会询问上层。只有两层都未命中时，Worker 才会运行。这意味着全球第一个请求会填充上层缓存，后续来自任何数据中心的请求都可以从上层缓存获取，即使该数据中心的下层缓存从未见过该请求，从而大幅提高缓存命中率。

ctx.props 实现多租户安全

当通过服务绑定调用另一个 Worker 时，调用方的 ctx.props 会成为缓存键的一部分。这意味着，传递不同 userId 或 tenantId 的调用方会获得独立的缓存条目，一个用户的数据永远不会泄露给另一个用户。这解决了认证 API 的缓存问题，使其从“不可缓存”变为“按用户安全缓存”。

缓存位于每个 Worker 入口点之间

Workers Cache 位于每个 Worker 入口点之前，包括默认导出、命名入口点以及通过 ctx.exports 进行的调用。你可以在 Wrangler 配置中，为每个入口点单独开启或关闭缓存。这让你可以将 Worker 构建为一系列小型入口点的链（如认证、路由、数据层），并在需要的地方插入缓存层。每个缓存的入口点都是一个独立的记忆化单元，拥有自己的键、TTL 和用于清除的标签命名空间。

框架的一流支持

如果你使用 Astro 构建，Cloudflare 适配器会自动为你配置 Workers Cache。只需在 Astro 配置中添加 cacheCloudflare 提供者即可。适配器会启用缓存、设置正确的响应头、附加 Cache-Tag 并提供一个 cache.invalidate() 辅助函数。

可观测性

Workers 可观测性仪表板现在会显示每个调用的缓存命中信息，包括缓存命中率、命中/未命中/更新/绕过等细分数据，帮助你了解缓存效果。

计费

缓存命中的请求不会运行 Worker，因此不产生 CPU 时间费用，但仍会按标准请求费率计费。缓存未命中和绕过的请求则正常计费（请求 + CPU 时间）。没有单独的 Workers Cache SKU 或按 GB 计算的缓存存储费。

未来计划

• 更智能地与 Smart Placement 协同工作，减少缓存未命中时的长距离网络跳转。
• 提高可缓存响应的大小限制。
• 为更多框架（如 TanStack Start、Next.js）提供集成。
• 提供一个 API 来将缓存的响应标记为过期（而非直接清除），以便后续请求能通过 stale-while-revalidate 快速获取过期响应。

尝试使用

Workers Cache 现已面向所有计划的 Worker 开放。只需在 wrangler.jsonc 中添加 "cache": { "enabled": true }，重新部署，并开始设置 Cache-Control 标头即可。

根据评论内容，总结主要观点如下：

正面评价（多数）： - 功能实用，解决了长期痛点。评论2："Finally proper stale-while-revalidate support!"；评论6："Amazing, exactly what Workers lacked... Waste of 3ms, times millions." - 遵循HTTP规范，设计合理。评论8："Huge props to just sticking with the HTTP spec... cache tags are a slick way to do invalidation." - 显著降低成本。评论4："consistently shipped features that reduce bills significantly... our bills went from £15k+ to £0."

批评与质疑（少数）： - 文章质量差，疑似AI生成。评论1："The post itself is a slop grenade."；评论9："obvious signs of LLM writing like no X, no Y etc." - 对技术必要性存疑。评论11："Reinventing the web... Do we need a global gateway to help us not screw up the basics?" - 期待更深入的技术解释。评论12："I was looking forward to the 'why it took us this long' explanation but it wasn't explicitly spelled out."

其他关注点： - 等待适配器跟进（评论3） - 与AWS Lambda对比（评论5） - 性能优势（评论10） - 对AI写作的普遍不满（评论14）