把刷新变成发布工艺
频繁刷新是命中率与发布稳定性的常见杀手。更稳的做法是把变更交给 URL：静态资源文件名带内容指纹（hash），内容一变文件名就变，边缘节点天然取到新版本；入口 HTML 用短 TTL 或协商缓存，始终指向新的资源清单。刷新只作为异常兜底，而不是每次发版的固定动作。
基本信息
| 指纹文件 | 内容变化则 URL 变化，边缘自动取新版本 |
|---|---|
| 入口文件 | index.html 用短 TTL，指向新指纹资源 |
| 兜底 | 异常场景用 URL 刷新，谨慎使用目录刷新 |
| 回滚 | 旧指纹文件保留一段时间，便于快速回滚 |
| 依赖 | 构建流程要产出带 hash 的文件名与引用清单 |
典型使用场景
- 前端项目接入构建流水线，产物自带 hash 文件名
- 大版本发布前只想刷新入口文件，不动全量静态资源
- 线上出现内容错误需要紧急修正，用单 URL 刷新做兜底
- 回滚时把入口指向旧指纹资源，无需等待边缘缓存过期
- 活动下线后清理活动专用资源，避免目录刷新影响其他内容
校验发布结果
校验发布结果
# 确认入口 HTML 已引用新指纹资源
curl -s https://cdn.example.com/ | grep -o -E 'app\.[0-9a-f]{6,}\.js'
# 确认新资源可访问且缓存头符合预期
curl -sI https://cdn.example.com/app.a1b2c3.js | grep -i -E 'HTTP/|cache-control|age'
# 确认旧资源仍在，便于回滚
curl -s -o /dev/null -w '%{http_code}\n' https://cdn.example.com/app.oldhash.js刷新方式对照
| 方式 | 适用场景 | 注意点 |
|---|---|---|
| URL 刷新 | 单个文件必须立即生效 | 配额消耗小，定位精确 |
| 目录刷新 | 整目录内容全部替换 | 影响面大，配额消耗高 |
| 指纹改名 | 常规静态资源发布 | 无需刷新，首选方案 |
| 回源预热 | 大文件发布后首访慢 | 提前把内容推到边缘 |
不要给入口 HTML 配长 TTL：发布后访客会长时间停留旧页面，引用的旧资源可能已被清理，表现为白屏或报错。
刷新不是即时完成：提交后各地节点逐步生效，期间可能出现新旧内容并存，验证时要连续多次请求而不是只看一次。