版本刚发布，部分用户却仍看到旧界面，另一些用户又遇到新旧资源混用。要做好缓存刷新与版本发布的一致性控制，关键不是在“清缓存”和“改版本”之间二选一，而是判断缓存对象是否可变、旧资源能否继续使用，以及发布顺序能否保证入口与资源匹配。
两种做法解决的问题不同
主动刷新缓存是让浏览器、代理或 CDN 提前移除指定内容。它适合内容已错误、必须尽快失效，或缓存键无法调整的情况。优点是能针对旧内容处理；缺点是刷新范围和生效时间受缓存层级影响，部分节点可能仍在传播，短时间内也可能增加源站请求。
更新资源版本则是让新版本使用不同的资源标识，使新请求不再命中旧缓存。可以通过构建产物中的版本化文件名或清单版本实现。它通常更适合常规发布：旧资源可继续服务仍在使用旧页面的用户，新用户按新入口获取新资源。不过，版本标识变了不代表资源已部署成功；若入口先更新、对应文件尚不可访问，仍会出现加载失败。
因此，缓存刷新与版本发布的一致性控制，核心是管理“入口何时切换”和“新旧资源何时可用”，而不是单纯追求缓存立即清空。
常规发布优先更新版本，紧急修复再刷新
对于 CSS 样式表、字体文件等随版本变化的静态文件，优先使用新版本标识，并让发布系统先上传新文件、再切换入口。旧文件在一段过渡期内保留，便于仍打开旧页面的用户继续加载。入口文件通常需要较短的缓存时间或重新验证机制，静态版本文件则可设置较长缓存；具体时长应结合发布频率、客户端行为和回滚要求决定。
主动刷新更适合以下情况：旧内容造成明显错误；敏感信息需要尽快从共享缓存移除；某项可变内容没有版本标识且不能等待自然过期。刷新前应确认目标路径、缓存键和缓存层级，避免把整个站点无差别清除。CDN purge（缓存清除）可以用于指定对象，但各服务商的覆盖范围与完成时间不同，不能把提交请求等同于所有用户立即看到新内容。
按顺序发布，降低新旧版本混用
- 先生成并检查新资源。确认新版本所需文件已上传，大小、类型和访问权限正常；至少检查代表性资源能够从预期的分发路径获取。
- 再发布入口和版本清单。让入口引用新版本标识。若部署涉及多个节点，确认它们不会在切换期间发布互不兼容的入口与资源。
- 观察实际响应。分别检查浏览器缓存和 CDN 响应头中的 Cache-Control、ETag 等信息，留意旧内容命中、资源 404 和加载失败。ETag 可支持客户端判断内容是否变化，但它本身不能替代发布顺序管理。
- 必要时定向刷新并准备回滚。若确认旧缓存导致故障，优先刷新明确的对象；回滚时恢复入口版本，并确保其引用的旧资源仍然可用。
Service Worker 场景要多检查一层
如果站点使用 Service Worker，它可能按自身缓存逻辑保存离线资源，单独刷新 CDN 未必能更新已经存入浏览器本地的内容。发布时应检查新版本的安装、激活和旧缓存清理策略，并避免在新资源尚未齐备时让新缓存接管。测试至少覆盖首次访问、已有旧版本的再次访问以及离线后恢复联网的情形。
选择结论：版本更新为主，刷新作为补救
对可版本化的静态资源，更新版本标识通常更可预测，也更利于回滚；对必须立即失效的可变内容，主动刷新更直接，但要接受传播和缓存层级带来的不确定性。较稳妥的方案是“新资源先就绪、入口后切换、旧资源暂时保留、异常时定向刷新”。这套缓存刷新与版本发布的一致性控制方式，能减少新旧内容交叉，也避免每次发布都依赖全量清缓存。
常见问题
发布后用户仍看到旧内容，先做什么？
先核对用户请求命中的缓存层、响应头和资源标识，再判断是浏览器缓存、CDN 缓存还是入口未更新；确认原因后再定向处理。
每次发布都应该清空 CDN 吗？
不必。资源版本变化且入口正确切换时，通常无需全量清除；全量刷新可能增加回源压力，也会影响未变更内容的缓存命中。
缓存时间设得越短越安全吗？
不一定。较短时间有助于更快重新验证，但会增加请求；应按资源是否可变、发布频率和回滚窗口分别设定，并通过实际响应确认策略生效。
