clients.claim()不能立刻控制已打开页面，因其仅对注册过Service Worker且完成激活的页面生效，而注册前加载的页面请求已绕过SW无法回溯；必须在activate事件中调用，并配合skipWaiting()、controllerchange监听或postMessage通知刷新。
clients.claim() 为什么不能立刻控制已打开页面？
clients.claim() 的作用是让新激活的 Service Worker 尝试接管当前 scope 下所有客户端（包括已打开但尚未被控制的页面），但它**不是即时生效的魔法开关**。关键限制在于：只有当页面本身执行过 navigator.serviceWorker.register()，且该注册流程已完成、Service Worker 已进入 activated 状态后，clients.claim() 才有机会起效；而那些在 SW 注册前就加载完成的页面，其 fetch 请求早已绕过 SW，不会自动“回溯”补控。
必须配合 skipWaiting() + activate 事件使用
单独在 install 事件里调用 skipWaiting()，只是让新 SW 跳过 waiting 状态、尽快进入 activating；真正执行 clients.claim() 的位置必须是 activate 事件回调中——因为只有这时 SW 才具备控制权：
self.addEventListener('activate', event => {
event.waitUntil(
Promise.all([
self.clients.claim(), // ✅ 必须在这里
caches.keys().then(keys =>
Promise.all(keys.map(key => caches.delete(key)))
)
])
);
});
常见错误是把 clients.claim() 放在 install 或全局作用域里，此时会静默失败（无报错但无效）。
页面端需要主动检查并刷新（必要时）
即使 SW 成功激活并 claim，已打开页面的当前生命周期内仍不会重发已有资源请求（比如已加载完的 JS/CSS）。要让页面真正走新 SW 的逻辑，通常需手动触发更新检测：
立即学习“前端免费学习笔记（深入）”；
- 在页面中监听
controllerchange事件，判断是否被新 SW 控制：if (navigator.serviceWorker.controller) { console.log('当前受', navigator.serviceWorker.controller.scriptURL, '控制'); } navigator.serviceWorker.addEventListener('controllerchange', () => { // 此时页面已被新 SW 接管，可提示用户刷新 location.reload(); }); - 更稳妥的做法是在
activate后主动postMessage给所有 clients，由页面决定是否 reload：// 在 activate 中 self.clients.matchAll().then(clients => { clients.forEach(client => client.postMessage({ type: 'SW_UPDATED' })); });
注意 scope 和 HTTPS 限制
clients.claim() 只能控制与当前 SW 同 scope 的页面。如果你注册时用了 scope: '/app/'，那么 /admin/ 下的页面永远不会被 claim。另外，Service Worker 只能在 HTTPS（或 localhost）下注册，否则 navigator.serviceWorker 根本不存在，后续所有操作都无从谈起。
最常被忽略的一点：页面 HTML 的 <script> 块必须在 DOM ready 后再调用 navigator.serviceWorker.register()，否则可能因注册时机太晚，导致页面加载完成时 SW 还没激活，从而错过首次控制机会。
