必须配合skipWaiting()和clients.claim()才能让新Service Worker立即接管当前页面：前者在install事件中跳过waiting状态，后者在activate事件中主动控制已打开页面，缺一不可且调用时机严格限定。
只写 self.skipWaiting() 或只写 clients.claim() 都不能让新 Service Worker 立即接管当前页面——必须两者配合，且严格限定在对应生命周期事件中调用。
为什么 skipWaiting() 必须放在 install 事件里
skipWaiting() 的作用是让刚安装完成的新 SW 跳过 waiting 状态，直接进入 activating；但它只对“正处于 waiting 状态”的实例生效，且仅在 install 回调中调用才被浏览器认可。
- 写在
activate里：无效，此时已错过时机，控制台可能静默忽略 - 写在全局作用域（比如文件开头）：部分浏览器会报
Failed to execute 'skipWaiting' on 'ServiceWorkerGlobalScope' - 包进
event.waitUntil(self.skipWaiting())：报错，因为skipWaiting()不返回 Promise - 正确位置是
install回调末尾，同步调用：self.addEventListener('install', event => { event.waitUntil(caches.open('v2').then(cache => cache.addAll(['/index.html', '/app.js']))); self.skipWaiting(); // ✅ 就在这里 });
为什么 clients.claim() 必须放在 activate 事件里
clients.claim() 是让新激活的 SW 尝试接管当前所有 clients（包括已打开但未被控制的页面），但它只能在 activate 阶段安全执行——此时 SW 已具备控制权，且旧版已释放或即将退出。
- 写在
install里：调用失败，Promise rejected，控制台提示InvalidStateError: Failed to execute 'claim' on 'Clients' - 不包进
event.waitUntil()：claim 可能未完成就结束 activate，导致部分页面未被接管 - 正确写法是：
self.addEventListener('activate', event => { event.waitUntil( self.clients.claim().then(() => console.log('All clients now controlled')) ); }); - 注意：它不会重发页面已发出的请求（如已加载的 JS），只是确保后续 fetch 交由新 SW 处理
前端注册脚本必须监听 controllerchange 并触发刷新
即使 SW 端两个方法都写对了，用户当前页面仍由旧 SW 控制，资源（HTML/JS/CSS）早已加载完毕。不刷新，就永远看不到新逻辑。
立即学习“前端免费学习笔记（深入）”；
- 必须在页面中监听
controllerchange事件，这是唯一可靠的接管完成信号 - 不要依赖
waiting或updatefound—— 它们只表示有新 SW 在 waiting，不代表已生效 - 最简可行做法：
if ('serviceWorker' in navigator) { navigator.serviceWorker.addEventListener('controllerchange', () => { location.reload(); // 或弹窗提示后由用户点击 }); } - 更稳妥的做法是结合 postMessage，在
activate后通知所有 client：self.clients.matchAll().then(clients => { clients.forEach(client => client.postMessage({ type: 'SW_ACTIVATED' })); });页面端再根据消息决定是否 reload
最容易被忽略的是缓存版本与 HTML 路由的耦合：如果 index.html 缓存在 v1 缓存中，而 JS 被 v2 缓存，skipWaiting() 和 clients.claim() 再快也没用——页面加载的仍是旧 HTML，里面引用的还是旧 JS 路径。静态资源必须同版本预缓存，且 HTML 本身要参与缓存键管理。
