上线后页面仍显示旧内容，不一定是发布失败；刷新缓存后出现新旧文件混杂，也不一定是缓存工具出错。关键在于理解缓存刷新与版本发布的一致性控制：发布决定新版本何时可用，缓存策略决定不同位置何时停止使用旧版本。以下五个误区，往往会让这两件事被错误地当成同一个操作。
误区一：代码发布完成，就代表用户拿到新版本
发布到源站，只说明源站内容已经更新。浏览器缓存、反向代理缓存和应用自身缓存，可能仍保存旧响应。反过来，如果 HTML 已经更新，却引用尚未部署完成的 JavaScript 文件，用户也可能遇到资源加载失败。
发布前应先列出相互依赖的内容，例如 HTML 页面、静态资源和接口响应，并确认新版本所需文件已经可用，再切换入口。采用滚动发布时，还要考虑请求可能被分配到新旧实例：新实例应能兼容发布窗口内仍在使用的旧数据或旧请求格式。
误区二：清一次缓存，就能让所有用户同步更新
缓存刷新通常针对指定系统、路径或缓存键，不等于清空每位用户设备里的浏览器缓存。不同缓存层的规则、过期时间和覆盖范围也不相同；刷新请求即使已发出，实际生效时间仍可能受系统处理和客户端状态影响。
先确认旧内容存在哪里，再选择动作：对于可由服务器控制的缓存，核对失效范围和执行结果；对于浏览器长期缓存的静态文件，优先使用带版本指纹的文件名，让新版本引用新地址，而不是期待远程清除所有旧副本。
误区三：文件名不变，刷新缓存就足够安全
如果每次发布都覆盖同一个文件名，缓存刷新期间，部分用户可能拿到新 HTML、旧脚本，或旧 HTML、新脚本。以浏览器页面引用脚本为例，文件名保持不变时，资源的新旧状态难以从地址直接区分。
更稳妥的做法是让内容变化对应新的资源标识，例如资源指纹文件名；页面切换到新版本后，旧文件保留一段兼容时间，再按存储成本和访问情况清理。这样做增加了短期存储占用，但比频繁全量缓存失效更容易控制。
误区四：刷新范围越大，发布风险越低
全量刷新可能让大量请求同时回到源站，增加源站负载；如果新版本尚未完全就绪，还可能把错误放大。只刷新过窄范围，则可能留下与新页面冲突的旧内容。范围大小并非越大越安全，应该按缓存键、路径和内容依赖来定。
按影响范围执行缓存刷新与版本发布的一致性控制
- 确定本次变更影响的 URL、资源和响应类型，检查是否存在按语言、设备或查询参数区分的缓存键。
- 先部署新版本依赖的静态资源，再更新页面或服务入口，避免入口先引用尚不可用的文件。
- 对确实需要失效的旧内容做定向刷新，并观察源站错误、缓存命中和关键页面是否正常。
- 保留旧版本资源及回滚路径；发现异常时，先恢复兼容的入口，再决定是否继续清理旧缓存。
误区五：回滚代码就能恢复发布前状态
回滚应用版本不会自动撤销已经发出的缓存刷新，也不一定能恢复已改变的数据格式或配置。尤其在灰度发布中，部分用户可能已经看到新版本，另一部分仍在使用旧版本，因此新旧版本短时间共存应是预先设计的状态，而不是意外情况。
把缓存刷新与版本发布的一致性控制写进发布清单：标明部署顺序、刷新对象、验证方式、旧资源保留时长和回滚责任人。具体保留多久要看资源类型、缓存过期设置及回滚窗口，不能用一个固定时长套用所有系统。
常见问题
发布后页面仍旧，先检查什么？
依次核对源站版本、页面响应、浏览器缓存和中间缓存，并确认页面引用的资源地址是否已变化。
静态资源适合频繁做缓存失效吗？
若资源有内容指纹且 HTML 引用新地址，通常不必频繁清理所有旧资源；入口页面和可变响应则应按实际缓存规则处理。
缓存刷新什么时候执行？
一般应在新内容就绪、发布顺序明确后执行。若刷新会增加源站压力，应分批操作并观察负载。
怎样降低新旧版本混用风险？
让资源地址可区分版本，保持接口与数据格式的短期兼容，并在灰度、切换和回滚过程中验证关键路径。归根结底，缓存刷新与版本发布的一致性控制靠的是明确顺序、范围和回退方案，而不是单独多按一次刷新。
