缓存刷新与版本化静态资源：让发布更新可预测地生效

📦 缓存刷新与资源版本化各自解决什么问题

缓存刷新让边缘节点删除对象或向源站重新验证；版本化静态资源则给内容变化分配新URL。两者不应被视作同一操作。长期缓存的JS、CSS、字体和图片适合版本化；入口HTML通常需要较短TTL或重验证。发布是否完整取决于引用链一致：新HTML必须引用已部署的新资源。

🔖 用内容哈希保证静态资源可追踪

构建系统可根据文件内容生成摘要后缀，例如main.a81f.js。文件内容改变，URL随之改变，边缘缓存不会将新旧内容视为同一对象。此类资源可使用较长缓存，并在条件适当时设置immutable。旧文件应保留至少覆盖旧HTML仍可能被访问的周期，避免回滚或延迟用户打开页面时出现404。

发布前比较构建清单与上传清单，验证每个被HTML引用的资源都存在于预期路径。内容哈希不自动修正错误的base路径、大小写差异或部署目录错位；这些问题需要直接检查构建产物和网络请求URL。

🧹 刷新范围应与对象更新方式匹配

固定URL对象无法版本化时，按单个URL刷新或触发重验证。目录通配可能失效大量热门对象，导致回源流量陡增。刷新也无法修正源站仍在提供旧文件的事实：缓存被清掉后，新回源响应仍会再次填入旧内容。提交刷新后，结合边缘缓存状态、对象年龄和返回内容观察实际传播，而不是只看操作提交成功。

🔍 判断更新是否真正到达用户

观察Age、缓存命中标识、ETag、Last-Modified和浏览器网络面板中的实际资源URL。304表示条件请求验证后可复用已有内容，不能单凭304认定刷新失败；需比较验证器是否变化及资源正文是否符合预期。若HTML已是新版本而脚本仍旧，检查HTML引用、浏览器缓存及服务工作线程；若边缘刷新后重新出现旧内容，则检查源站版本和部署同步。

✅ 发布验收清单

1. 保存发布前首页引用资源URL及代表资源摘要。
2. 发布后确认HTML引用新版本URL，资源返回正确状态码、内容类型和摘要。
3. 重复请求检查缓存行为符合预期，观察边缘回源量没有异常尖峰。
4. 验证回滚入口仍能访问旧版本依赖，刷新范围与操作记录匹配。

只刷新HTML不会改变浏览器已缓存的固定资源URL；只有引用链、源站文件和缓存策略共同一致，用户才能稳定获得新版本。✅