本页列出不适用 Workers 缓存的场景，并说明它与你可能已在使用的其他缓存之间的关系。
仅 GET 和 HEAD 请求会被缓存。POST、PUT、PATCH、DELETE 及其他方法始终会调用 Worker。
同一 URL 的 GET 和 HEAD 共享单个缓存条目。在冷缓存上到达的 HEAD 请求会在内部转换为 GET，以便用完整资源填充缓存。请参阅缓存键。
如需缓存非幂等请求的响应，请在 Worker 中显式处理——例如，将请求体哈希为合成 URL，并发起内部 GET 子请求。
WebSocket 升级请求（带 Upgrade: websocket 的 GET）会绕过缓存，始终调用 Worker。WebSocket 会话本质上有状态，不适合作为缓存单元。
仅 WorkerEntrypoint 上的 fetch() 调用会经过 Workers 缓存。像 ctx.exports.Backend.getUser(id) 这样的自定义 RPC 方法会绕过缓存，始终运行被调用方，无论 entrypoint 的 cache.enabled 设置如何。
如需缓存当前以 RPC 方法暴露的工作，请将其重构为独立 entrypoint 上的 fetch 处理程序，并通过 fetch() 调用。
Workers 缓存永不存储以下响应，即使带有显式 Cache-Control 指令：
520–526（Cloudflare 故障保护响应）被视为瞬时错误，始终重新运行 Worker。- Worker 返回的
206 Partial Content不会被存储——Workers 缓存期望 Worker 返回完整的200响应，并自行进行范围切片。请参阅Range请求了解支持的模式。
Workers 缓存仅适用于 Worker entrypoint 上 fetch 处理程序处理的 HTTP 请求。以下调用类型始终运行，不涉及缓存：
- Cron Triggers — 通过
scheduled处理程序的定时调用。 - Queue 消费者 — 通过
queue处理程序投递的消息。 - Workflows — 工作流步骤执行。
- Tail Workers — 追踪事件处理程序。
- Durable Objects — Durable Object 调用永不缓存，无论处理程序或方法如何。如需缓存 Durable Object 的 HTTP 响应，请在启用缓存的 Worker entrypoint 后包装它。请参阅缓存 Durable Object 响应。
没有「按主机清除」模式。缓存属于 Worker，而非域名——主机不是缓存键的一部分，因此按主机清除无法映射到缓存实际存储的内容。请改用按标签清除、按路径前缀清除或 purgeEverything。
没有 API 可以在构建时用生成的响应预填充缓存。响应只有在至少被提供一次后才会被缓存。如需让预渲染内容对第一个请求者可用，请使用静态资源（Static Assets）。
响应大小限制与 Cloudflare zone 缓存相同。各套餐限制请参阅可缓存大小限制。
Cache-Tag 值的数量、长度和字符集限制与 Cloudflare zone 缓存相同。完整列表请参阅缓存标签限制。
ctx.cache.purge() 使用与 zone 清除 API 相同的速率限制系统。账户适用速率请参阅可用性与限制。
Workers 缓存是你的 Worker 的缓存，而非 zone 的缓存。它以 Worker 本身作为配置面，因此无需额外配置规则或设置。以下均不适用于 Workers Caching：
| Zone 级功能 | Workers 缓存中的等效做法 |
|---|---|
| Cache Rules 和 Cache Response Rules | 在 Worker 中设置 Cache-Control 标头，或根据请求分支并返回不同标头。 |
| Cache Rules 中的缓存键自定义 | Workers 缓存有自身的键组成；请参阅缓存键。通过改写请求来塑造键（例如，在网关 Worker 中改写 URL 或设置 ctx.props）。 |
| Zone 级缓存级别设置（bypass / standard / aggressive / ignore query string） | 响应上的 Cache-Control 标头在每次请求级别表达相同意图。 |
| Zone 的默认 cached-file-extensions 列表 | Workers 缓存会缓存标头表明可缓存的任何响应，与文件扩展名无关。 |
| 自定义分层缓存拓扑 | Workers 缓存默认使用通用分层缓存拓扑。Worker 可在任意位置执行，固定自定义拓扑不适用——未来与 Smart Placement 的集成可能进一步定制分层。 |
| 在缓存前修改请求或响应的 Rulesets | 在 Worker 代码中于返回前转换请求或响应。 |
要影响 Worker 的缓存，请修改 Worker。Cache-Control 标头、ctx.props、service binding 组合和 ctx.cache.purge() 覆盖配置面。
Cache API 是独立的编程式缓存存储。它与 Workers 缓存无关——对一方的操作不影响另一方，ctx.cache.purge() 才会使 Workers 缓存条目失效。
对于新 Worker，优先使用 Workers 缓存。Cache API 设计上是一个更低层的原语：
- 它不读穿——响应仅在 Worker 显式调用
put()时缓存，每个请求在进入时仍会执行 Worker。 - 它不会为同一资源合并并发请求。突发流量访问新 URL 会为每个请求调用一次 Worker。
- 它不参与分层缓存。
Workers 缓存自动提供以上三项。当你需要细粒度编程控制时，Cache API 仍然有用。
Workers 缓存是位于 Worker 前面的服务端缓存。它与 Worker 向自身源站发起的出站 fetch() 子请求前面的缓存是分开的。两者独立运行：fetch() 子请求命中可省去访问源站的行程，而 Workers 缓存命中则 Worker 完全不必运行。
cf 属性在两者上的行为不同：
cf 属性 |
向源站的出站 fetch() |
在 ctx.exports.<Entrypoint>.fetch() 上 |
|---|---|---|
cf.cacheKey |
支持 | 支持 — 请参阅自定义缓存键 |
cf.cacheControl |
支持 | 支持 — 请参阅从调用 Worker 覆盖 Cache-Control |
cf.cacheTtl |
支持 | 不支持 — 通过被调用方返回 Cache-Control: max-age=N（或 s-maxage=N）设置 TTL，或从调用方用 cf.cacheControl 覆盖 |
cf.cacheEverything |
支持 | 不支持 — Workers 缓存根据响应的 Cache-Control 决定可缓存性；无法强制缓存本不可缓存的响应 |
以下功能正在开发中：
- 无需 Wrangler 即可启用缓存的仪表板 UI。
- Workers Observability 中的缓存分析。