核心问题是客户端用旧缓存连新服务器导致资源不一致；需通过哈希静态资源强缓存、html强制校验、接口禁用缓存、切换提示降级四层保障实现平滑过渡。
主备服务器切换时，浏览器缓存干扰的核心问题不是“缓存没清掉”，而是客户端仍用旧缓存资源，却连上了新服务器——而新服务器可能尚未同步全部静态资源、或版本不一致、或响应头策略不同，导致 JS 执行报错、样式错乱、接口 404 或数据不一致。
要让客户端平滑过渡，关键在于：缓存策略与部署节奏对齐，而非依赖“清除”。以下是实际可行的四层保障措施：
主备切换前：静态资源必须带内容哈希 + 强缓存
- JS/CSS/图片等构建产物必须生成带内容哈希的文件名（如
app.a1b2c3.js），由 Webpack/Vite 自动完成 - 服务端对这类资源统一返回：
Cache-Control: public, max-age=31536000, immutable
这样即使主服务器下线、备机刚上线，只要它已同步了这批哈希文件，浏览器就可安全复用缓存，无需重下 - ❌ 避免用时间戳或版本号（如
app.js?v=2.1）：它破坏缓存复用性，每次切换都触发全量下载
HTML 文件必须强制校验，不缓存内容
- 主备服务器对
index.html（或入口 HTML）必须返回：Cache-Control: no-cache, must-revalidate
并启用ETag或Last-Modified - 效果：每次访问 HTML 时，浏览器会发条件请求（带
If-None-Match），由当前生效的服务器（主 or 备）决定返回304或新 HTML - 新 HTML 中引用的哈希文件路径自然更新，从而引导浏览器加载匹配的新资源
接口请求需兼容双环境，避免缓存放大风险
- 对关键业务接口（如
/api/config、/api/user），前端在 fetch 时显式禁用缓存：fetch('/api/config', { cache: 'no-store' })或添加防缓存头：
headers: { 'Cache-Control': 'no-cache' } - 后端在主备切换窗口期，确保两套环境的 API 响应结构、字段、状态码完全兼容（至少向前兼容 1 个大版本）
- 敏感操作（如提交、支付）跳过任何本地缓存，一律走实时网络
切换过程中主动提示 + 安全降级（可选但推荐）
- 前端可定时请求一个轻量版版本探针（如
/version.json），比对buildId或gitCommit - 若发现 HTML 已更新但关键 JS 仍加载失败（如
script error监控捕获），可：- 自动触发
location.reload(true)（硬重载，跳过所有缓存） - 或显示“检测到更新，点击刷新获取最新功能”按钮，由用户确认
- 自动触发
- Service Worker 场景下，新 SW 激活时调用
self.clients.claim()并清理旧缓存（如caches.delete('static-v1')），确保接管立即生效
本质上，主备切换不是缓存问题，而是资源一致性问题。靠“清缓存”解决不了，靠“管住 HTML 的新鲜度 + 锁死静态资源的不可变性 + 控制接口的时效性”，才能让客户端在无感中完成切换。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
