一图速览
关键结论
- Cloudflare近日正式面向所有Workers用户推出专属前置分层缓存能力Workers Cache。这项能力无需额外配置其他Cloudflare服务，仅通过Wrangler一行配置加标准HTTP头即可开启，大幅降低边缘计算的调用成本与响应延迟。对于大量把Workers作为全栈应用部署底座的开发者而言，这一升级补上了边缘SSR场景的最后一块短板。
- 这篇文章主要影响关注「Cloudflare Workers」的开发者、技术负责人和内容读者。
- 后续应继续观察它在「工程实践」里的真实采用成本、替代路径和长期影响。
影响对象
- Cloudflare Workers 相关开发者和技术负责人
- 正在跟踪 工程实践 趋势的产品与工程团队
风险 / 机会
| 机会 | 风险 |
|---|---|
| 把原有正文沉淀为可扫描的判断框架，降低读者理解成本 | 旧文没有完整 AI 初稿上下文，结构化判断需要后续人工复核 |
| 用封面、一图速览和表格提升转发与复读效率 | 如果后续事实更新，旧文中的判断需要同步修订 |
我的判断
这篇旧文值得保留，但不能只以段落形态存在。我的判断是：先把它补成「事实 + 解读 + 判断」的结构化版本，让读者能快速判断是否相关；后续若进入正式重写流程，再用最新信源替换这里的保守判断。
信源对比
| 信源 | 角色 | 关键事实 | 用途 |
|---|---|---|---|
| #1 | 站内旧文 | 既有正文与标题摘要 | 作为 backfill 的基础语料 |
导语
过去几年，Cloudflare Workers凭借全球节点覆盖、轻量化运行时、极低的调用成本，成为大量开发者部署边缘服务、全栈SSR应用的首选底座。但随着越来越多开发者直接把Worker作为业务源站而非请求转发层使用，原有架构中缺失前置缓存的问题逐渐凸显：所有动态请求都要触发Worker执行，既拉高了CPU计费成本，也增加了不必要的响应延迟。Cloudflare在2026年7月正式推出的Workers Cache，恰恰从底层架构层面补上了这一短板。
事实综述
本次推出的Workers Cache是完全与Worker实例绑定的分层缓存层，直接部署在Worker的所有入口之前，和Cloudflare原有域名级的缓存体系完全独立。开发者开启这项能力的成本极低，只需要在Wrangler配置文件中新增一行cache: { enabled: true }即可，无需配置任何域名级的缓存规则、页面规则，也不需要额外开通其他Cloudflare服务。
开启后，缓存规则完全通过开发者熟悉的标准HTTP头控制：在Worker返回的响应中设置Cache-Control头即可定义缓存时长、是否允许缓存、异步更新策略等，同时支持Cache-Tag给缓存内容打标签，Vary头实现内容协商场景下的多版本缓存。运行逻辑上，所有发往Worker的请求会优先命中缓存：如果有新鲜的缓存内容，Cloudflare会直接返回响应，完全不触发Worker执行，也不计入CPU计费；缓存未命中时才会运行Worker生成响应，如果响应标记为可缓存则自动存入全球缓存节点，供后续所有地区的请求复用。
缓存清理也完全在Worker代码内可控，开发者调用ctx.cache.purge接口即可按标签、路径前缀清理缓存，清理范围仅限当前Worker的缓存空间，不会影响同一域名下部署的其他服务，也不会污染生产环境或其他租户的缓存。哪怕是部署在workers.dev子域名、预览环境、Workers for Platforms多租户体系下的Worker，都能完整使用这套缓存能力，每个环境的缓存相互隔离。
这是我们一直希望Workers拥有的缓存API。 （出自Cloudflare Blog，2026年7月）
Workers Cache目前已经向所有套餐的Workers用户开放使用。
解读与评价
这次升级的核心价值，是彻底适配了Workers当前的主流使用场景。2017年Workers刚推出时，定位是放在源站和缓存之间的请求处理层，适合做请求改写、A/B测试、流量过滤等场景，Worker在缓存前的架构完全够用。但现在Next.js、Remix、Astro、SvelteKit等主流前端框架都原生支持编译为Worker部署，大量开发者已经直接把Worker作为业务源站使用，原有架构下没有任何前置缓存，开发者只能二选一：要么全量预渲染成静态资源，每次内容更新都要等待数分钟甚至数小时的全量构建；要么每次请求都动态渲染，承担更高的成本和更长的延迟。
Workers Cache给出了第三种更优的解法：动态渲染一次后自动缓存，既保留了服务端渲染的内容灵活性，又能达到静态站点的响应速度，还不需要任何框架专属的增量静态生成等能力，完全基于标准HTTP协议实现，几乎没有迁移成本。
对于中国开发者而言，这次升级的实际收益非常明确：第一是成本优化，对于大部分内容更新频率不高的站点、API服务，开启缓存后90%以上的请求都不会触发Worker执行，CPU计费成本可以降低一个数量级；第二是出海业务的体验提升，面向全球用户的应用缓存命中后直接从就近节点返回，响应延迟可以压缩到数十毫秒，远高于动态渲染的速度；第三是架构简化，之前开发者需要自己用KV、Durable Object实现业务层缓存，还要处理缓存失效、多环境隔离等问题，现在只需要配置标准HTTP头就能搞定，大幅降低了开发和维护成本。
当然开发者在使用时也需要注意：Vary头的配置要尽量收敛，避免因请求头变体太多导致缓存命中率下降；要根据业务的内容更新频率合理设置max-age和stale-while-revalidate的时长，平衡内容新鲜度和缓存命中率；对于内容更新的场景，尽量用标签清理缓存而非全量清理，避免不必要的性能损耗。
信源
- Your Worker can now have its own cache in front of it — Cloudflare Blog