「Service Worker 曾被寄予厚望，如今却逐渐被遗忘。」一位开发者在复盘多個实际案例后得出了这个结论。
他认为，在大多数业务场景下，Service Worker 并非最优解——用更简单的方式就能解决同样的问题。
为什么 Service Worker 失宠了
Service Worker 在 2014 年被引入浏览器，本意是让网页在后台运行、拦截网络请求、实现离线访问。它曾是「渐进式 Web 应用（PWA）」的核心技术，被视为 Web 的未来。
但早期采用者们很快发现了代价：一旦缓存策略出错，用户会持续收到过期的「僵尸版本」应用。更棘手的是，修复需要发布一个新的「终止开关」脚本，然后等待用户客户端逐个更新——这个过程可能持续数天。
几个典型场景的分析
Slack 的即时启动：有人认为 Service Worker 通过缓存全部资源实现了「零网络请求启动」。但作者指出，对于几乎不变的资产，HTTP 缓存加上内容哈希（Cache-Control: public, max-age=31536000, immutable）已经足够。只要文件名带哈希值，浏览器会直接从缓存读取，无需额外的 Service Worker 层。
部署后旧资源的兼容问题：代码分割意味着每次部署都可能让客户端的旧缓存指向已不存在的文件。一些平台（如 Vercel）提供「倾斜保护」，但更多项目只能靠 Service Worker 来兜底。作者认为，内容哈希文件名的设计天然支持新旧版本共存——Settings-a3f8b2.js 和 Settings-c91d44.js 可以同时存在于 CDN 上，无需 Service Worker 来「保管」旧资源。
视频清单重写（Mux 的案例）：视频播放器在挂载时就发起请求，早于 Service Worker 初始化，导致清单重写失效。作者建议将这个逻辑搬到服务端：清单只是一个文本文件，服务端重写比客户端拦截更可靠，也不必担心视频流量经过额外的基础设施。
真正离不开 Service Worker 的场景
作者也承认，有些能力只有 Service Worker 能提供：
- 离线支持：真正的离线可用，需要在客户端拦截请求并返回本地资源
- 推送通知：服务端主动触达用户，没有替代方案
- 后台同步：在网络恢复后自动提交用户操作
但他同时指出，Partytown（将脚本运行在 Web Worker 中的库）的 Service Worker 版本本身就是备选方案——当跨域隔离不可用时才启用；而 Mock Service Worker（MSW）在现代 SSR 框架下更多用 setupServer 替代，而非真正的 Service Worker。
结论
Service Worker 不是万能药。作者建议：除非你明确需要离线能力、推送通知或后台同步，否则先考虑 HTTP 缓存、内容哈希、服务端重写等更简单的方案。「我还没遇到过一个真正只有 Service Worker 才能解决的问题」——这是作者的原话，也是这篇文章的核心立场。
编注：信源为独立技术博客，材料围绕多个 Service Worker 应用场景逐一分析，主线为技术选型的反思与质疑，未涉及 Service Worker 在推送/离线场景的替代方案讨论。