Service Worker 激活后不会立即接管已打开页面，需下一次导航或刷新才生效；可通过 activate 阶段调用 clients.claim() 并触发 client.navigate() 实现立即控制，或由页面监听更新后提示用户手动刷新。
service worker 激活后默认不会立即接管已打开的页面，这是设计使然，不是 bug。关键在于理解“控制权移交”的触发时机，并主动干预。
为什么新 Service Worker 不会立刻控制旧标签页？
浏览器为保障稳定性，要求页面在**下一次导航或刷新时**才由新 Service Worker 控制。已加载完成的页面（包括其 fetch 请求、缓存行为）仍由旧 SW 管理，即使新 SW 已处于 activated 状态。
手动触发页面重载以获取新控制权
在新 Service Worker 的 activate 事件中，调用 self.clients.claim() 并通知已打开的客户端刷新：
- 在新 SW 文件中添加：
self.addEventListener('activate', event => {
event.waitUntil(
Promise.all([
self.clients.claim(), // 立即尝试接管当前 clients（对已激活但未受控的页面有效）
self.clients.matchAll({ type: 'window' }).then(clients => {
clients.forEach(client => client.navigate(client.url)); // 触发同 URL 导航，等效于刷新
})
])
);
});
-
clients.claim()让新 SW 尝试接管所有当前 clients（包括尚未被任何 SW 控制的页面）； -
client.navigate()是最可靠的方式——它不关闭页面，而是重新加载当前 URL，从而触发新 SW 的 fetch 事件并建立控制关系； - 注意：该操作需在
activate阶段执行，且仅对同源、可见的 window clients 生效。
前端页面监听更新并引导用户刷新
更友好的做法是让页面自己感知更新，并提示用户：“有新版本，点击刷新”：
- 注册 SW 后，监听
controllerchange事件（当页面 controller 切换时触发）； - 在新 SW 安装完成时（
waiting状态），通过postMessage主动通知页面； - 页面收到消息后，显示轻量提示，点击后调用
window.location.reload(true)强制走网络+新 SW。
避免常见陷阱
以下操作无法真正实现“立即控制”：
- 仅调用
skipWaiting()—— 它只加速 waiting → activating，不改变已有页面的 controller； - 在
install阶段调用clients.claim()—— 此时 SW 还未 activate，无效； - 依赖
self.skipWaiting()+self.clients.claim()但没做页面刷新 —— 页面仍由旧 SW 处理后续请求。
