Workbox 让 PWA 离线能力变成一个运营问题

为什么这件事重要

离线能力是 PWA 里最容易被误解的承诺之一。用户并不关心你有没有注册 service worker；他们关心的是网络变差、缓存过期、接口失败时，这个已安装应用是否还能给出可预期的反馈。

Chrome 的 Workbox 文档把它描述为 production-ready service worker libraries and tooling，并且围绕生命周期、缓存策略、部署预期、存储配额、fallback、更新和调试来组织内容。这个角度很重要：离线不是一个开关，而是一套运营模型。

发生了什么变化

Workbox 的文档结构不像普通营销页，更像生产运维手册。它覆盖 service worker lifecycle、runtime caching、precaching 的注意事项、storage quota、navigation preload、fallback responses、更新处理和调试。

对 PWA 团队来说，这其实是在提醒：service worker 可以增加信任，也可能破坏信任。一个设计糟糕的 service worker，可能让用户卡在旧版本、打不开新路由、看到错误缓存，甚至无法判断问题来自网络还是应用本身。

开发者应该检查什么

在把应用标成“offline-ready”之前，建议按运营系统来审查：

• 明确哪些路由必须离线可用，哪些路由只需要清晰 fallback。
• 按资源类型选择缓存策略，不要用一个全局规则处理所有请求。
• 测试更新行为，避免用户在发布后仍停留在旧 app shell。
• 关注 storage quota，避免无限缓存媒体文件或接口响应。
• 为坏 service worker 版本准备日志、回滚和恢复路径。
• 在 OpenPWA listing 里解释“离线可用”到底意味着什么，而不是只写一个标签。

OpenPWA 的判断

OpenPWA 不应该因为一个应用注册了 service worker 就给高分。更有价值的信号是：这个应用是否有诚实的离线契约，哪些能力可用，哪些能力降级，更新如何到达已安装用户。

Workbox 对 OpenPWA 的价值，不只是提供工具，而是把 PWA 质量变成一组具体可问的问题。能回答这些问题的开发者，才更接近交付一个值得用户长期安装的应用。

来源：

• Chrome for Developers: Workbox