在使用 Cloudflare Worker 构建全球加速、灰度发布、多源站调度系统时，缓存体系设计是决定系统稳定性与可控性的核心因素。
很多工程师会同时使用：
- Cloudflare CDN 自动缓存
- Worker 内置的
caches.default缓存
但如果没有明确区分两者职责，很容易出现：
页面版本混乱、发布失控、缓存击穿、数据不一致
本文将从工程实践角度，系统讲清：
- CDN 缓存和 Worker 缓存的本质区别
- 为什么 HTML 不应交给 CDN 缓存
- 如何设计工业级双层缓存架构
- 完整请求流程与版本更新逻辑（Mermaid 图）
一、缓存的本质分工
在 Cloudflare 边缘网络中，请求实际会经过两层潜在缓存系统：
用户 → Cloudflare CDN Cache → Cloudflare Worker → Worker Cache → 源站
它们并不是同一层级，而是定位完全不同的系统组件。
二、CDN Cache：自动化高速公共缓存
特点
- 位于 Cloudflare PoP 边缘节点
- 自动命中与回源
- 延迟极低（毫秒级）
- 几乎无计算成本
优势
✅ 极致性能
✅ 超大容量
✅ 自动分布式
局限
❌ 缓存 Key 不可精细控制
❌ 无法感知业务版本、灰度逻辑
❌ 不适合频繁更新内容
适用场景
👉 静态资源：
- JS
- CSS
- 图片
- 视频
通常配合：
Cache-Control: public, max-age=31536000, immutable
实现一年级别缓存。
三、Worker Cache：可控的逻辑缓存层
Worker 内置缓存允许开发者自定义：
- cacheKey
- 版本参数
- 地区维度
- 灰度标识
特点
- 完全由代码控制
- 可嵌入业务逻辑
- 可做版本隔离
优势
✅ 高度可控
✅ 支持发布系统
✅ 支持多版本共存
局限
❌ 相比 CDN 稍慢
❌ 消耗 Worker 计算资源
适用场景
👉 HTML 页面
👉 接口聚合结果
👉 动态内容
四、为什么 HTML 不应该交给 CDN 缓存？
在现代工程实践中，HTML 通常具备：
- 版本更新频繁
- 灰度发布需求
- 多源站调度
- A/B 测试
如果 HTML 被 CDN 缓存：
- CDN 无法识别版本参数
- Worker 逻辑被绕过
- 发布行为不可控
最终会导致：
❗ 部分用户看到旧页面
❗ 部分用户看到新页面
❗ 灰度失效
这在工程上被称为：
缓存失控风险
五、推荐的工业级缓存职责模型
HTML
Cache-Control: no-store
效果：
➡ CDN 不缓存
➡ 所有请求进入 Worker
➡ 由 Worker Cache 管控
静态资源
Cache-Control: public, max-age=31536000, immutable
效果：
➡ 浏览器缓存
➡ CDN 长期缓存
➡ 零回源
六、完整请求流程（含版本控制）
七、版本更新时的自动刷新机制
通过引入构建版本号：
_v = BUILD_VERSION
缓存 Key 变为：
/page?_v=20260203
更新后：
/page?_v=20260204
效果
✔ 自动绕过旧缓存
✔ 强制回源
✔ 生成新缓存
无需：
❌ 手动 purge
❌ 等待过期
八、版本更新流程图
九、最终架构总结
┌──────────────┐
│ CDN Cache │ ← 静态资源
└──────────────┘
↓
用户请求 → Worker（逻辑调度） → Worker Cache（HTML/动态内容） → 源站
职责划分原则：
| 类型 | 使用缓存 | 目的 |
|---|---|---|
| HTML | Worker Cache | 可控、可发布 |
| API | Worker Cache | 动态聚合 |
| JS/CSS/IMG | CDN Cache | 极致性能 |
十、一句话工程结论
CDN 管稳定资源
Worker 管动态逻辑
或者更直观一点：
CDN 缓存“死内容”
Worker 缓存“活页面”
结语
通过将 CDN Cache 与 Worker Cache 职责彻底拆分：
✅ 发布可控
✅ 性能极致
✅ 架构清晰
✅ 易扩展
将获得一套：
🌍 支持全球调度
🚀 支持秒级更新
🧠 支持复杂业务逻辑
的工业级边缘架构体系。
转载自CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/solocao/article/details/157685571
