skipWaiting() 在 install 事件中调用时生效，使新 Service Worker 跳过 waiting 阶段进入 activating 状态；但需配合 activate 阶段的 clients.claim() 才能让当前页面立即受控。
skipWaiting 什么时候生效？
skipWaiting() 不是“立刻激活”，而是把等待中的新 Service Worker 推入激活态——前提是它已经跳过 waiting 阶段，且没有被旧版 SW 占着 clients（比如页面没刷新、没关闭）。常见错误是调用 skipWaiting() 后页面仍用旧脚本，因为旧 SW 还在控制着当前页面，而新 SW 只在下一次导航才接管。
- 必须在新 SW 的
install事件中调用，不能在activate或外部 JS 里调用 - 仅对当前正在安装的 SW 实例有效；已进入
waiting状态的 SW 不会响应后续的skipWaiting()调用 - 如果旧 SW 正在控制页面（
navigator.serviceWorker.controller !== null），新 SW 激活后不会自动接管已有页面，需手动clients.claim()或刷新
如何在 install 阶段正确调用 skipWaiting
最简可靠写法是在新 SW 文件顶部的 install 回调里直接触发：
self.addEventListener('install', (event) => {
event.waitUntil(
caches.open('v2').then((cache) => cache.addAll(['/index.html', '/app.js']))
);
self.skipWaiting(); // ✅ 放在这里，不是在 waitUntil 里，也不是在 then 里
});
-
skipWaiting()是同步方法，不返回 Promise，无需event.waitUntil()包裹 - 不要写成
event.waitUntil(self.skipWaiting())—— 这会报错，因为skipWaiting()不返回 Promise - 如果你用了 Workbox，改用
workbox.core.skipWaiting()（它内部做了兼容处理）
为什么页面没更新？检查 clients.claim()
即使新 SW 激活了，已有页面仍由旧 SW 控制。要让当前页面立即受新 SW 管理，必须在新 SW 的 activate 阶段调用 clients.claim()：
self.addEventListener('activate', (event) => {
event.waitUntil(
self.clients.claim() // ✅ 让新 SW 立即接管所有已打开的 clients
);
});
-
clients.claim()只影响当前 origin 下、未被其他 SW 控制的页面（比如刚打开的 tab） - 如果页面已加载完成，
fetch事件仍走旧 SW，直到刷新或导航；claim()无法 retroactively 替换已发出的请求 - 常见误操作：只调用
skipWaiting()，漏掉clients.claim()，结果“激活了但没生效”
生产环境慎用自动 skipWaiting
自动跳过等待在开发时方便，但上线后可能引发不一致问题：
立即学习“前端免费学习笔记（深入）”；
- 新 SW 的缓存策略和旧页面逻辑不兼容（比如 v2 删除了 v1 缓存的某个 API 响应，而旧页面还在读取）
- 多个标签页同时运行，有的用 v1，有的用 v2，共享的 IndexedDB Schema 或 localStorage 格式不一致
- Chrome DevTools 的 Application → Service Workers 面板里勾选 “Update on reload” 本质就是每次 reload 都强制
skipWaiting+claim，但这只适合调试
真正稳妥的做法是：前端加一个「有新版本可用」提示，用户点击后执行 registration.waiting.postMessage({type: 'SKIP_WAITING'})，再监听 message 触发 skipWaiting() 和 location.reload()。
跳过等待本身很简单，难的是让整个生命周期里的资源加载、状态迁移、多页协同不出岔子。别只盯着 skipWaiting() 这一行代码。
