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 处理后续请求。