service worker生命周期是状态驱动的异步过程，注册仅提交申请，install和activate可能被阻塞或跳过；需通过waituntil保证缓存可靠性，用skipwaiting和clients.claim推进控制权交接。
Service Worker 生命周期不是线性流程，而是状态驱动的异步过程；注册成功不等于立即生效，install 和 activate 都可能被阻塞或跳过。
为什么 navigator.serviceWorker.register() 后页面没离线？
注册只是“提交申请”，不触发安装。浏览器会按需（比如页面刷新、导航到同 scope 下新页面）才启动 install 流程。常见误判点：
- 注册脚本放在
末尾但未加window.addEventListener('load', ...)，导致注册时机过早或失败 - 脚本路径错误，返回 404 —— 此时控制台不会报明显错误，但
chrome://serviceworker-internals里能看到 “failed to fetch” - 作用域（
scope）配置越界，例如用register('/sw.js', {scope: '/admin/'})却在/下访问，SW 不会控制该页面 - 开发中反复注册未更新版本号，浏览器判定为“冗余”，直接跳过 install
install 事件里必须用 event.waitUntil()
不调用 waitUntil()，install 会瞬间完成，后续缓存操作变成“后台任务”，无法保证资源写入成功。更糟的是：如果缓存失败但没被拦截，SW 会进入 installed 状态却无有效缓存。
-
waitUntil()接收一个 Promise，只要它 reject，整个 install 就失败，SW 进入redundant状态 - 常见错误是忘记 return：写成
event.waitUntil(caches.open(...))而不是event.waitUntil(caches.open(...).then(...)) - 缓存列表含 404 资源时，
caches.addAll()会整体失败 —— 建议拆成单个cache.add()并捕获错误，或预检资源可用性
activate 事件里不清理旧缓存，会导致磁盘爆满
每次更新 SW 脚本，旧版本仍驻留，其缓存也继续存在。若不主动清理，caches.keys() 列表会持续膨胀，尤其在开发阶段频繁改名缓存（如 v1 → v2）。
- 激活阶段用
event.waitUntil()包裹清理逻辑，确保新 SW 完全接管前旧缓存已删 - 典型写法：
caches.keys().then(keys => Promise.all(keys.map(k => k.startsWith('my-cache-') && caches.delete(k)))) - 注意：不能在
install阶段删旧缓存 —— 此时旧 SW 可能还在运行，caches.delete()会失败
怎么确认当前 SW 处于哪个状态？
别只看 console 日志，实际状态得查运行时对象：
- 页面中检查
navigator.serviceWorker.controller?.state（当前控制页面的 SW 状态） - 通过
registration.installing/registration.waiting/registration.active获取对应实例，再读其.state - 状态值只能是字符串：
"installing"、"installed"、"activating"、"activated"、"redundant" - 最易忽略的是
"waiting"：install 成功但没激活，通常因为有旧 SW 正在控制页面 —— 此时需手动调用skipWaiting()或等用户关闭所有标签页
生命周期里没有“运行中”概念，只有事件触发点；self.skipWaiting() 和 clients.claim() 是让更新立即生效的关键动作，但它们本身不改变状态机，只影响控制权交接时机。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
