调试Service Worker需理解其事件驱动模型和生命周期限制，避免在install/activate/fetch中使用未resolve的Promise、同步阻塞或无限循环，否则会导致卡在installing/waiting状态；应通过Application面板查状态、Console看报错，并确保event.waitUntil()和event.respondWith()正确调用。
调试 Service Worker 脚本时避免死循环，关键在于理解其事件驱动模型和生命周期限制——它没有传统页面的执行上下文，不能依赖 setInterval、while(true) 或未受控的递归调用。一旦在 install、activate 或 fetch 事件处理中引入无限等待或阻塞逻辑，SW 会卡在 installing/activating 状态，甚至导致注册失败或页面无法接管。
识别 Service Worker 中的潜在死循环点
Service Worker 的主线程不支持同步阻塞操作，以下写法极易引发不可恢复的挂起：
- 在 event.waitUntil() 内使用未 resolve 的 Promise（如漏写 resolve、reject，或 await 一个永不完成的异步操作）
- 在 fetch 事件中手动调用 fetch() 后未返回响应，也未 catch 错误，导致 event.respondWith() 永远不被调用
- 错误地在 install 事件中执行同步 while 循环（例如遍历大数组做耗时计算），虽不报错但会触发浏览器强制终止
- 在 activate 事件里调用 caches.delete() 时传入错误的缓存名，Promise 拒绝后未捕获，导致 waitUntil 失败、激活中断
用开发者工具定位卡住的生命周期阶段
打开 Chrome / Edge 的 Application → Service Workers 面板：
- 状态显示 Installing 且长时间不动 → 检查 install 事件中 caches.open() 或 caches.addAll() 是否因路径错误、HTTPS 缺失或 Promise reject 而中断
- 状态为 Waiting → 新版 SW 已注册但未激活，通常因旧 SW 仍在控制页面；可勾选 “Update on reload” 并刷新，或手动点击 “Skip Waiting”
- 状态为 Activated 却无网络拦截效果 → 打开 Console 查看是否有 unhandledrejection 报错，尤其关注 fetch 事件中 respondWith() 是否被遗漏或条件分支未覆盖
编写健壮 SW 代码的防护习惯
从源头降低风险，不是等出问题再调试：
- 所有 event.waitUntil() 必须包裹一个明确 resolve/reject 的 Promise，避免裸 await；建议统一用 .catch(e => console.error('SW error:', e))
- fetch 事件中必须确保 event.respondWith() 被且仅被调用一次；可用 if-else 或 switch 明确分流，结尾加 fallback：event.respondWith(fetch(event.request))
- 避免在 SW 中做 CPU 密集型操作；如需处理大量数据，改用 Web Worker + postMessage 协作
- 本地开发时，在 sw.js 开头加入 self.skipWaiting() 和 clients.claim()（仅限调试环境），加速新版本生效，缩短验证周期
快速验证缓存与离线行为是否正常
确认 SW 没卡住后，进一步验证逻辑是否按预期运行：
- 在 Application → Cache Storage 中查看对应缓存名是否存在、条目数量是否匹配 precache 列表
- 切换到 Network 面板，勾选 “Offline”，刷新页面：若看到 200 (from ServiceWorker)，说明缓存命中；若出现 failed 或 pending，说明 fetch 逻辑未兜底
- 在 Console 中临时添加 console.log('installing…')、console.log('activated!')，观察日志是否完整输出，缺失即代表某阶段异常终止
