当旧网站注册的 service worker 缓存了整个站点，导致新部署的网站无法加载时，需主动覆盖或触发其更新；本文提供从客户端兼容性角度出发的可靠解决方案，包括 sw 覆盖、缓存欺骗与强制更新策略。
当旧网站注册的 service worker 缓存了整个站点，导致新部署的网站无法加载时，需主动覆盖或触发其更新；本文提供从客户端兼容性角度出发的可靠解决方案，包括 sw 覆盖、缓存欺骗与强制更新策略。
在现代 PWA（渐进式 Web 应用）开发中，Service Worker 的强缓存能力是一把双刃剑：它能显著提升离线体验和首屏性能，但也可能在网站重构或迁移后引发“缓存僵局”——用户访问 www.example.com 时，浏览器完全绕过服务器，直接从旧 SW 缓存中返回上一版本页面，甚至不发起任何网络请求。
要解决这一问题，关键在于让旧 Service Worker 主动卸载或被新版本接管。由于你无法控制用户本地浏览器行为，必须通过服务端可部署的策略实现“静默修复”。
✅ 方案一：覆盖旧 Service Worker 脚本（首选）
首先确认旧 SW 的注册路径（通常为 /sw.js 或 /service-worker.js）。可通过浏览器 DevTools → Application → Service Workers 查看当前激活的脚本 URL。然后，在完全相同的路径下部署一个空的、合法的 Service Worker 文件：
// sw.js（最小化有效 SW）
self.addEventListener('install', (e) => e.waitUntil(self.skipWaiting()));
self.addEventListener('activate', (e) => e.waitUntil(self.clients.claim()));⚠️ 注意：该文件必须：
- 返回
Content-Type: application/javascript； - HTTP 状态码为
200（不可返回404或重定向）； - 与原 SW 同源、同路径、且字节级不同（哪怕只加一个空格，也能触发更新机制）。
若旧 SW 使用 skipWaiting() + clients.claim()，此方法通常可在用户第二次访问时生效。
✅ 方案二：欺骗版本检查逻辑（应对防御性注册）
部分旧 SW 实现会校验前端资源哈希（如 app-data.json 中的 webpackCompilationHash），仅当哈希变更才执行 register()。此时单纯覆盖 sw.js 无效。
评估聊天、邮件、电话、社交平台私信（DM）或电商平台客服团队的服务质量。适用于团队需要制定 QA 评分卡、故障模式分析、辅导计划、校准检查清单或服务改进简报，但无法访问实时工单系统、CRM 或联络中心系统的情况。
你需要：
- 定位该校验源（常为 JSON 配置接口，如
/app-data.json）； - 在相同路径返回伪造响应，其中
webpackCompilationHash字段设为与之前不同的随机字符串； - 确保该响应缓存头为
Cache-Control: no-cache, must-revalidate，避免被中间代理缓存。
示例（Node.js/Express）：
app.get('/app-data.json', (req, res) => {
res.set('Cache-Control', 'no-cache, must-revalidate');
res.json({
webpackCompilationHash: 'deadbeef1234567890abcdef', // 强制变更
version: '2.0.0',
// ...其他原有字段
});
});此举将触发旧注册逻辑判定“资源已更新”，进而尝试安装新 SW（即你部署的空 SW），最终完成接管。
✅ 补充建议：前端兜底（增强鲁棒性）
在新网站的主入口 HTML 中加入以下脚本（置于 内，越早执行越好），主动尝试解除旧 SW：
<script>
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.getRegistrations().then(regs => {
regs.forEach(reg => {
// 仅对匹配旧作用域的注册执行注销（谨慎使用）
if (reg.active && reg.scope.includes('www.')) {
reg.unregister().then(() => console.log('SW unregistered'));
}
});
});
});
}
</script>⚠️ 注意：unregister() 仅对当前页面作用域内的注册生效，且无法立即终止已激活的 SW；但它可加速清理流程，配合上述服务端策略效果更佳。
总结
解决“旧 SW 锁死新网站”的核心思路是：利用浏览器 SW 更新机制的天然触发条件（脚本内容变更 / 依赖资源变更），而非依赖用户手动操作。优先覆盖 SW 脚本，再辅以版本数据欺骗与前端主动注销，三者结合可在 99%+ 用户场景下实现无缝过渡。部署后建议通过 Lighthouse 或手动清缓存验证：打开 DevTools → Application → Clear storage → 勾选 “Service workers” 和 “Cache storage”，刷新确认是否加载新版资源。
