本文详解在域名复用场景下，因遗留 service worker 强制缓存导致新网站无法生效的紧急修复方案，涵盖服务端覆盖、缓存欺骗与客户端主动注销三类实战策略。
本文详解在域名复用场景下，因遗留 service worker 强制缓存导致新网站无法生效的紧急修复方案，涵盖服务端覆盖、缓存欺骗与客户端主动注销三类实战策略。
当客户沿用原有域名（如 www.example.com）上线新版网站时，若旧站注册了全局缓存型 Service Worker（SW），用户再次访问将完全绕过服务器——HTML、CSS、JS 全部从 Cache Storage 加载，导致新代码“不可见”。这不是常规缓存问题，而是 SW 的持久化接管行为，必须主动打破注册链。
✅ 核心解决思路：三步递进式清除
1. 服务端覆盖：部署空 SW 覆盖旧注册点
Service Worker 的更新机制依赖 URL 和响应内容的比对。若你能确定旧 SW 的注册路径（如 /sw.js 或 /service-worker.js），最直接的方式是：在原路径部署一个最小化、无功能的新 SW 文件：
// /sw.js（部署到与旧 SW 完全相同的 URL）
self.addEventListener('install', (e) => e.waitUntil(self.skipWaiting()));
self.addEventListener('activate', (e) => e.waitUntil(self.clients.claim()));
// 不监听 fetch，不缓存任何资源 —— 彻底交还控制权给网络⚠️ 注意：此方法仅在旧 SW 未启用 updateViaCache: 'none' 或强校验逻辑时有效。若旧注册脚本中包含类似 if (currentHash !== savedHash) skipRegistration() 的保护机制，该 SW 将被拒绝安装。
2. 缓存欺骗：触发旧 SW 的“更新感知”逻辑
若第一步失败，说明旧 SW 实现了版本校验（如读取 app-data.json 中的 webpackCompilationHash）。此时需伪造其依赖的校验源，诱导其判定“内容已变更”，从而卸载自身并允许新 SW 注册：
评估聊天、邮件、电话、社交平台私信（DM）或电商平台客服团队的服务质量。适用于团队需要制定 QA 评分卡、故障模式分析、辅导计划、校准检查清单或服务改进简报，但无法访问实时工单系统、CRM 或联络中心系统的情况。
- 找出旧 SW 中用于比对的动态资源（常用：
/app-data.json、/manifest.json、/version.txt）； - 在相同路径部署伪造响应，修改关键字段（如
hash、version、timestamp）； - 示例（Nginx 配置伪造
/app-data.json）：location = /app-data.json { add_header Content-Type application/json; return 200 '{"webpackCompilationHash":"deadbeef1234567890","buildTime":1717023456}'; }用户刷新后，旧 SW 检测到哈希变化，自动进入更新流程，为你的新 SW 让出注册机会。
3. 客户端强制注销：面向存量用户的兜底方案
对已受困用户，可在新网站的入口 HTML 中嵌入一次性清理脚本（建议放在 顶部，确保早于任何 SW 相关逻辑执行）：
<script>
// 仅执行一次：检测并注销所有已注册 SW
if ('serviceWorker' in navigator) {
window.addEventListener('load', async () => {
try {
const registrations = await navigator.serviceWorker.getRegistrations();
for (const reg of registrations) {
await reg.unregister();
}
// 可选：刷新页面确保加载新资源
if (registrations.length > 0) location.reload();
} catch (e) {
console.warn('SW cleanup failed:', e);
}
});
}
</script>? 重要提醒：
- 此脚本需部署在
www.子域下才有效（SW 作用域严格匹配）； - 生产环境建议添加
localStorage标记，避免重复执行； - 长期方案：新版 SW 应显式调用
caches.delete(cacheName)清理旧缓存，并在activate事件中self.clients.claim()立即接管页面。
最终，结合服务端覆盖 + 校验欺骗 + 客户端兜底，可 100% 解除旧 SW 的“缓存锁死”，确保所有用户在首次刷新后无缝迁移到新版网站。
