每个 PWA 在追求离线能力之前，都需要 service worker 恢复预案

为什么这件事重要

MDN 把 service worker 描述为位于 Web 应用、浏览器和网络之间的代理服务器。这个位置让它拥有很强的控制力：可以启用离线体验、拦截请求、更新资源，还能连接推送和后台同步。对已安装 PWA 来说，service worker 实际上成了产品契约的一部分。如果它出错，即使服务器正常，用户也会觉得应用坏了。

发生了什么变化

关键变化在于生命周期。service worker 会基于 origin 和 path 注册，然后经历下载、安装、激活和后续更新。它没有 DOM 访问能力，运行在异步 worker 上，并且只在 secure context 中可用。这些限制提高了安全性，但也让调试和恢复路径不同于普通页面脚本。

开发者应该检查什么

• 明确 scope，不要让一个 worker 控制超出应用边界的站点范围。
• 上线前测试 install、activate、update、unregister 全流程。
• 为坏缓存和错误 fetch handler 准备恢复路径。
• 把 HTTPS 当成生产要求，而不是形式化检查。
• 说明哪些失败会走缓存、哪些走 fallback、哪些需要清晰错误提示。

OpenPWA 的判断

OpenPWA 应该把 service worker 质量看成运营成熟度。listing 可以写应用是否有离线行为，但更应该追问：团队是否能从一次坏的离线发布中恢复？最可信的 PWA 不是缓存最多的应用，而是失败和更新都可预期的应用。

来源：

• MDN: Service Worker API