service worker安装阶段是预加载离线资源，通过install事件和event.waituntil()确保缓存完成；激活阶段是清理旧缓存并正式接管页面，通过activate事件和self.skipwaiting()可跳过等待。
理解 Service Worker 的安装与激活，关键在于抓住“缓存准备”和“控制权交接”这两个动作的本质，而不是只记事件名。
安装阶段：不是启动，而是预加载离线资源
安装（install）不是让 Service Worker “跑起来”，而是让它把未来离线时要用的文件提前存进缓存。这个过程由 install 事件 触发，但真正起作用的是 event.waitUntil()：
- 必须用
event.waitUntil(promise)包裹异步操作，比如打开缓存、添加资源；否则浏览器会认为安装立刻完成，跳过缓存步骤 - 缓存列表里写错一个路径（比如
/style.css实际是/styles.css），整个 promise 就 reject，安装失败，Service Worker 进入 redundant 状态，不会激活 - 常见做法是缓存 HTML、CSS、JS、关键图片等静态资源，不建议在 install 阶段发起网络请求或处理用户数据
激活阶段：清理旧缓存 + 正式接管页面
激活（activate）发生在新 Service Worker 已安装、且旧版本已完全退出后。它标志着控制权正式移交，此时才能安全执行清理和策略更新：
- 监听 activate 事件，用
event.waitUntil()清理旧版本缓存（例如删除my-cache-v1，只保留my-cache-v2） - 激活过程中抛出错误，通常不会导致 Service Worker 失效——因为此时页面已不受旧 SW 控制，新 SW 已具备接管能力
- 如果希望新 SW 立即生效（跳过 waiting 阶段），可在 install 回调末尾调用
self.skipWaiting()，但需确保不影响当前用户操作（比如正在提交表单）
等待阶段：不是卡住，而是安全过渡的设计
安装成功后，Service Worker 不会马上激活，而是进入 waiting 状态。这不是 bug，是浏览器的保护机制：
- 已有页面正被旧版 Service Worker 控制，直接切换可能导致请求拦截逻辑不一致、缓存混乱或资源加载异常
- 只有当所有受控页面关闭，或用户刷新页面，新 SW 才会从
installed走向activating - 可通过
navigator.serviceWorker.ready判断是否已激活并可使用；监听controllerchange事件可获知控制权变更
状态与调试：用 state 和生命周期事件定位问题
Service Worker 共有 6 种状态（parsed → installing → installed → activating → activated → redundant），每种都可通过 registration.installing?.state 或 registration.waiting?.state 查看：
- 如果始终卡在
installing，检查 sw.js 是否有语法错误，或cache.addAll()中某个 URL 返回 404/500 - 如果长期停留在
installed，说明还在 waiting，确认是否有旧页面未关闭，或没调用skipWaiting() - 在 DevTools 的 Application → Service Workers 面板中，勾选 “Update on reload” 和 “Offline”，能更直观观察各阶段行为
