你可能并不需要 Service Worker：一场关于前端缓存与架构的反思

背景

Service Worker（服务工作者）曾被视为 Web 开发的“下一个大事件”，旨在赋予 Web 应用离线能力、后台同步和推送通知等原生应用般的特性。然而，随着时间推移，它的热度逐渐消退，甚至在许多现代开发场景中变得鲜有人提及。

近期，开发者 Neciu 发布了一篇深度文章，剖析了 Service Worker 在实际生产环境中的用例，并指出许多开发者在 2019 年左右尝试引入 Service Worker 后，因缓存策略不当导致应用出现“陈旧版本（stale app）”问题，最终不得不移除它。这一现象引发了作者对 Service Worker 必要性的重新审视：在当前的 Web 技术栈下，我们是否真的离不开它？

核心内容

文章通过拆解 Neciu 提出的几个典型用例，论证了大多数场景下，原生浏览器缓存或服务器端方案足以替代 Service Worker。

Slack 的即时启动：缓存是否过度设计？

Slack 利用 Service Worker 缓存全套资源并重新水合（rehydrate） Redux 状态，使得 UI 能在任何网络请求完成前渲染。这看似完美，但作者认为其核心优势被高估了。

• 资源未变，无需 SW：Slack 观察发现，不同启动周期间的资源几乎不变。对于未更改的资源，利用 HTTP 原生缓存机制（Content Hash + Cache-Control: public, max-age=31536000, immutable）即可实现直接从缓存读取，无需 Service Worker 介入。
• 离线 vs. 加速：Service Worker 无法提供真正的“无网络启动”，因为 HTML 和前置数据仍需获取。如果应用不需要离线支持，仅为了加速启动，原生缓存更简单高效。

部署期间的“僵尸”代码块：版本冲突的替代方案

在频繁部署（如 Vercel 的 Skew Protection 或每日数百次 CI 构建）中，旧客户端可能请求已删除的资源，导致 404 错误。Neciu 建议用 Service Worker 缓存应用，但这意味着要在后台缓存所有内容。

• SW 方案的弊端：为了处理版本更新，Service Worker 需要维护一个包含所有资产版本的清单（Manifest）。这不仅违背了路由/代码分割（Code Splitting）的初衷，还导致每次无效化时客户端需重新拉取整个应用，造成巨大的无效负载。
• 更优解：保留静态资产：作者建议不删除旧资源，而是让它们在存储桶中保留一段宽限期（Grace Period）。由于使用了内容哈希文件名（如 Settings-a3f8b2.js 与 Settings-c91d44.js 共存），部署永远不会覆盖旧文件。
• 主线程轮询：既然 Service Worker 不能无限期在后台运行，核心更新逻辑应放在主应用层。通过页面轮询（Polling）或监听 visibilitychange 事件来检查版本，比依赖 Service Worker 更可控且无需额外缓存负担。

Mux 的 Manifest 重写：客户端逻辑的错位

Mux 遇到一个问题：视频播放器挂载时即开始请求资源，早于同页 Service Worker 获取控制权的时间，导致必须将 Worker 注册在索引页并链接到播放器页。

• 服务端重写更优：这种逻辑错位表明该功能不应由客户端处理。将 Manifest 重写移至服务端（Server-side）更稳健且易于测试。
• 边缘计算支持：文章提到，由于 Cloudflare Workers 等边缘运行时实现了相同的 fetch 事件 API，Mux 可以直接将逻辑部署到边缘，无需复杂的客户端 Worker 注册流程。

Partytown 与 Mock Service Worker：SW 只是备选或名称误导

• Partytown：虽然名为 Partytown，但其 Service Worker 版本实际上是回退（Fallback）方案。理想情况下，它优先使用 Atomics 和 SharedArrayBuffer。但由于 SharedArrayBuffer 需要跨域隔离头（Cross-Origin Isolation），这往往会导致第三方嵌入内容失效。因此，实践中 Service Worker 回退方案的使用频率高于预期，但它更像是一个逃生舱口，而非首选。
• Mock Service Worker (MSW)：随着服务器驱动渲染（Server-Driven Rendering）和数据加载策略的普及，开发者更多使用 setupServer（通过修补 Node 内部实现）进行模拟。尽管库名包含 Service Worker，但在传统 SPA 之外，它往往并不真正依赖 Service Worker。

关键要点

• 原生缓存足以应对大多数加速需求：对于静态资源，利用 HTTP 缓存头（Cache-Control）和内容哈希比 Service Worker 更简单、更标准。
• Service Worker 的核心不可替代价值：目前仅有离线支持、推送通知和后台同步是 Service Worker 真正无可替代的功能。
• 缓存策略的复杂性陷阱：Service Worker 的缓存失效和版本管理极其复杂，容易导致“陈旧应用”问题，修复往往需要发送“开关（killswitch）”并等待客户端更新，维护成本高。
• 服务端/边缘端优于客户端：涉及资源重写、版本控制等逻辑，移至服务端或边缘计算节点（如 Cloudflare Workers）通常更健壮、易测试且性能更好。
• 不要为了用而用：许多声称需要 Service Worker 的场景，通过主线程轮询、原生 HTTP 缓存或服务端逻辑即可解决，引入 SW 可能带来不必要的复杂性和维护负担。

意义与影响

这篇文章反映了 Web 开发从“过度工程化”向“回归本质”的趋势。

1. 简化前端架构：开发者应重新评估对 Service Worker 的依赖。在没有明确离线或后台任务需求时，优先使用浏览器原生能力和服务端逻辑，可以显著降低应用复杂度和调试成本。
2. 缓存策略的规范化：强调利用标准的 HTTP 缓存机制（如 Immutable Cache-Control）来处理静态资源，而非依赖自定义的 JS 逻辑，这有助于提高兼容性和性能。
3. 对 CI/CD 流程的启示：在频繁部署的场景下，通过保留旧版本资源（而非立即删除）并结合客户端轮询，是一种比 Service Worker 更轻量、更可靠的版本管理策略。
4. 技术选型的理性回归：Service Worker 并非银弹。在评估技术方案时，应仔细权衡其带来的收益（如离线体验）与成本（如缓存失效复杂性、调试难度），避免盲目跟风。

总之，除非你需要真正的离线功能或后台能力，否则“你可能并不需要 Service Worker”。