Neciu 最近分析了一些服务工作者的有趣用例。我确实感到‘被看见’了：在我的调查中，两个“在2019年尝试过一个并将其删除”的人都讲述了相似的故事，细节有所不同：一个缓存策略不佳的服务工作者向用户提供了过时的应用，而修复需要发送一个关闭开关工作者并等待数天以便客户端获取更新，因为损坏的工作者控制了更新检查的时间。服务工作者发布时，我是一个早期采用者，并迅速在类似场景中犯了同样的错误。让我们来解析一下该帖子的几个例子（如果您还没有读过，请先阅读！）。 在实际中的用例 Slack 的即时启动 帖子中最引人注目的例子是 Slack 的：缓存完整的资产集并重新激活 Redux 状态，以便在发出任何网络请求之前，UI 可以渲染。尽管资产部分听起来有些夸大，然而：他们观察到几乎没有任何资产在启动之间发生变化。周二早上打开 Slack 的用户下载的 JavaScript 和周一早上下载的是一样的。HTTP 缓存应该足以缓解这个问题，并且要简单得多。对于未更改的资产，内容哈希加上 Cache-Control: public, max-age=31536000, immutable 意味着它们应该直接从缓存中提供。 它无法提供无网络启动：您仍需要获取 HTML 和任何先决数据。我认为这更多的是一个“我是否需要离线支持？”的问题。对于 Slack 来说，可以，但对于许多应用程序，可能不需要。如果您只是想避免重复下载相同的资产，只需对其进行哈希处理并利用原生缓存即可。 保持死代码块在部署中的存活 这是一个有趣的例子。一些供应商，如 Vercel，具有‘偏斜保护’ ，但我们大多数人过去都遇到过：客户端上旧的打包会导致 404，因为引用的资产不再存在。您发布的越多，这就越频繁成为问题（如果您真的实践 CI，可能每天会发布数百次）。Neciu 在这里的解决方案是使用服务工作者在本地缓存应用。然而，这意味着在后台缓存所有内容：{ " version " : "2026.06.04-1412" , // 这会在哪里结束？ " assets " : [ "/assets/index-c91d44.js" , "/assets/Settings-c91d44.js" ] } jsonc 在我看来，这违背了路由/代码拆分的目的。当然，您会得到更快的初始渲染，但这意味着每次失效都强制客户端重新拉取整个应用程序。对于我参与过的大多数应用程序，这将导致一个庞大且大部分浪费的有效载荷。我们无法确定用户将访问哪些组件/页面，所以理论上我们需要将整个清单的内容拉下来。如果相反，我们仅保留静态资产（在宽限期内）呢？与其直接删除它们，不如让它们在一个存储桶中继续存在。通过内容哈希文件名，一次部署从不覆盖任何内容：Settings-a3f8b2.js 和 Settings-c91d44.js 可以共存。由于服务工作者不能无限期地下运行，因此核心重新拉取逻辑仍然必须驻留在主应用中：页面驱动轮询，而不是服务工作者，因为服务工作者在每次可见更改时都需检查版本，所以从后台返回的标签页会立即检查。因此，这也不需要服务工作者。 Mux 的清单重写 这很巧妙，但感觉不应该在客户端上进行。文章中提到的漏洞实际上是客户端逻辑的症状：视频播放器在挂载时开始获取数据，而在同一页面的工作者能够接管之前，因此他们必须在索引页面上注册工作者并链接到播放器页面。相反，应该将重写移动到服务器端，在那里它更健壮且更易于测试。只有清单（一个文本文件）需要重写，因此无需担心通过额外的基础设施层拉取大量视频。文章中也特别提到：……因为像 Cloudflare Workers 这样的边缘运行时实现了相同的获取事件 API，他们在不更改的情况下将拼接工作者部署到 Cloudflare 并获得了一个工作 URL。 Partytown 是一个好的例子，尽管需要指出的是，服务工作者版本实际上是后备方案：Partytown 将在浏览器可用时使用 Atomics 和 SharedArrayBuffer。不幸的是，SharedArrayBuffer 仅在跨源隔离下工作，这些标头往往会破坏第三方嵌入。因此在实践中，服务工作者后备方案的使用频率超过您的预期，但它仍然更多是一个逃生阀。 Mock Service Worker 这取决于您构建的内容，但随着向服务器驱动的渲染策略和数据加载的转变，您可能实际上在使用 setupServer（它修补 Node 内部）。只有传统的 SPA 最终会得到一个字面的服务工作者，尽管这个库的名字是这样的。那么，您需要一个服务工作者吗？您可以使用服务工作者做很多很酷的事情。