您可以使用 Workers 在 Cloudflare 网络上自定义缓存行为。Workers 在请求生命周期中作为中间件运行——单个 Worker 处理请求和响应两个阶段。当请求到达时，它在检查缓存之前命中 Worker。Worker 可以修改传入请求（例如，重写 URL 或添加标头），然后调用 fetch() 使请求继续通过缓存。当响应返回时——无论来自缓存还是源站服务器——Worker 也可以在发送给访问者之前修改响应。
下图说明了 Workers 与 Cache 之间常见的交互流程。
- 访问者 (a) 请求 URL，此请求被定向到 Worker。Worker 然后可以与请求交互，使用 (b)
fetch()从源站服务器请求内容，或向访问者发送 (f) 响应。 - 如果内容被缓存，缓存向 Worker 发送 (e) 响应，Worker 可以在向访问者发送 (f) 响应之前修改响应。
- 在 Workers 中使用缓存规则时，缓存规则必须匹配
fetch()(b) 请求中 URL 的属性——如标头、主机名或 URL 路径——而非原始访问者 URL/主机 (a)。否则，规则将不会应用。
以下是 Workers 可用于自定义缓存行为的一些示例：
-
Modify Response：从缓存检索内容后调整或增强内容，确保响应是最新的或针对特定需求定制。
-
Signed URLs：生成有时间限制的签名 URL 以控制访问并增强安全性。
-
Personalized Response：基于用户数据提供个性化内容，同时使用缓存资源以减少源站服务器负载。
-
Reduce Latency：从靠近访问者的数据中心提供内容，减少加载时间并改善用户体验。
您还可以使用 Snippets 进行轻量级修改，如标头更改、重定向和 JWT 验证，而无需部署完整的 Worker 脚本。Snippets 在所有付费计划中免费包含，但有更严格的资源限制（5 ms 执行时间，32 KB 包大小）。
Workers 提供两种与缓存交互的方式。当 Worker 向源站发出子请求时使用 fetch()。当 Worker 在没有后端源站的情况下生成响应时使用 Cache API。
-
fetch()：当 Worker 调用
fetch()时，请求通过 Cloudflare 的缓存和 Tiered Cache（如果已启用）。您可以通过在请求的cf对象上设置属性来控制缓存行为——包括 time-to-live (TTL) 值、自定义缓存键和缓存标头。有关更多详情，请参阅使用 fetch 缓存。 -
Cache API：允许您使用
caches.default或caches.open()以编程方式在 Cloudflare 缓存中存储、检索和删除响应。与fetch()不同，Cache API 仅操作处理当前请求的数据中心中的缓存——它不与 Tiered Cache 交互。当您需要缓存非来自源站的响应时使用 Cache API。有关更多详情，请参阅使用 Cache API。
要了解更多关于 Cache 和 Workers 如何交互的信息，请参阅 Workers 中的 Cache。