Web Worker 与 Service Worker：它们是什么以及为什么重要

Web Workers vs Service Workers：快速概览

浏览器大多数 JavaScript 都在主线程上运行——这是处理用户输入、动画以及页面绘制的同一个地方。当那儿发生繁重工作（解析大数据、图像处理、复杂计算）时，UI 会出现卡顿或“冻结”。Workers 的作用是将某些任务移出主线程或移出页面的直接控制范围，以保持应用响应迅速。

Workers 解决的问题

如果你的页面正在执行一个 200ms 的计算，浏览器就无法平滑滚动、立即响应点击或保持 60fps 的动画。Workers 通过让你在后台完成工作，而主线程专注于界面，来缓解这个问题。

简要定义

Web Worker 是你从页面创建的后台 JavaScript 线程。它最适合那些会阻塞 UI 的 CPU 密集型任务。

Service Worker 是一种特殊的 Worker，位于你的 Web 应用与网络之间。它可以拦截请求、缓存响应，并启用诸如离线支持和推送通知等功能。

一个简单的心智模型："线程" vs "网络代理"

把 Web Worker 想象成在另一间房间做计算的助手。你发送消息给它，它工作，然后再回消息给你。

把 Service Worker 想象成门口的守卫。页面、脚本和 API 的请求都会经过它，它可以决定是去网络抓取、从缓存返回，还是用自定义响应处理。

本文你将学到的内容

读完后你会知道：

• 何时使用 Web Worker 来提升性能（以及它不能访问哪些东西）
• Service Worker 为离线缓存、更新和 PWA 行为带来的能力
• 像 postMessage 这样的消息传递在 Worker 模型中如何工作，以及为什么 Cache Storage API 对离线很重要

以上建立了“为什么”和心智模型——接下来我们深入讨论每种 Worker 的行为及其在真实项目中的定位。

浏览器为什么要使用 Workers

当你打开一个网页时，你 "感受到" 的大部分事情都在主线程上发生。它负责绘制像素（渲染）、响应点击和触摸（输入），以及运行大量 JavaScript。

主线程像一个共用的结账队列

由于渲染、输入处理和 JavaScript 经常在同一线程上轮流执行，一个慢任务会让其他所有任务等待。这就是为什么性能问题往往表现为响应性问题，而不仅仅是“代码慢”。

阻塞给用户的感受：

• 滚动出现卡顿（jank）
• 按钮点击没有立即响应
• 打字滞后
• 动画短暂停止

异步并不等同于并行

JavaScript 有许多异步 API——fetch()、定时器、事件——它们帮助你避免空等。但异步并不会神奇地让繁重工作与渲染同时进行。

如果你在主线程上做昂贵计算（图像处理、大 JSON 解析、加密、复杂过滤），它仍然会与 UI 更新竞争。“异步”可以推迟何时运行，但它可能仍在主线程上执行，并在执行时导致卡顿。

Workers 在浏览器架构中的位置

Workers 的存在是为了让浏览器在执行有意义工作的同时保持页面响应：

• Web Workers 允许在后台线程上运行 JavaScript，用于 CPU 密集型任务。\n- Service Workers 与任何单个页面分离，更像是一个网络和缓存层，即使页面未打开也能工作。

简言之：Workers 是保护主线程的一种方式，让你的应用在后台做真实工作时仍然保持交互性。

什么是 Web Worker？

Web Worker 是一种在主线程之外运行 JavaScript 的方式。Worker 在自己的后台线程中运行，不与 UI（渲染、滚动、响应点击）竞争，这样繁重任务就能完成而不让页面感觉“卡住”。

可以把它想象为：页面专注于用户交互，而 Worker 处理那些 CPU 密集型的工作，例如解析大文件、做数值计算或为图表准备数据。

它运行在哪里

Web Worker 在独立线程且有自己的全局作用域中运行。它仍然可以访问许多 Web API（定时器、许多浏览器支持的 fetch、crypto 等），但它被刻意与页面隔离。

Dedicated Worker 与 Shared Worker

常见的两种形式：

• Dedicated Worker：与单个页面/标签页相连。当该页面关闭时，Worker 通常会被终止。\n- Shared Worker：可以被同一源的多个页面/标签页共享，适合在标签页间协调工作（例如共享一个连接或同步状态）。

如果你从未使用过 Workers，大多数示例都是 Dedicated Worker。

Web Worker 如何通信

Worker 无法直接调用页面中的函数。通信通过发送消息进行：

• 页面使用 postMessage() 向 Worker 发送数据。\n- Worker 也通过 postMessage() 回应。\n- 数据通过 structured clone 算法传输，支持许多内建类型（对象、数组、字符串、数字、Maps/Sets、ArrayBuffer 等）。

对于大型二进制数据，你通常可以通过转移 ArrayBuffer 的所有权来提升性能（避免复制），让消息传递保持高效。

常见限制（出于设计考虑）

由于 Worker 是隔离的，因此存在一些关键限制：

• 不能直接访问 DOM：Worker 无法读取或修改页面的 HTML、CSS 或布局。\n- 全局不同：没有 window 或 document，Worker 在 self（Worker 全局作用域）下运行，可用 API 与主页面不同。\n- 异步思维：一切基于消息，因此你的代码结构围绕发送工作并接收结果。

合理使用时，Web Worker 是在不改变应用逻辑的情况下提升主线程性能的最简单方式之一——只改变繁重工作的执行位置。

何时使用 Web Worker（何时不该用）

当你的页面因为在主线程上执行过多 JavaScript 导致“卡住”时，Web Worker 非常适合。主线程还负责用户交互和渲染，所以那儿的繁重任务会引发卡顿、延迟点击和滚动冻结。

适合 Web Worker 的场景

当你的任务 CPU 密集且不需要直接访问 DOM 时使用 Web Worker：

• 繁重计算：计算、模拟、数据挖掘。\n- 解析与转换：大 JSON 解析、CSV 解析、模式验证。\n- 压缩/解压：zip/gzip 等工作负载、编码/解码。\n- 图像处理：缩放、滤镜、生成缩略图（在支持的浏览器中常与 OffscreenCanvas 配合）。

实际示例：如果你接收到一个大 JSON，有解析时 UI 会卡顿，就把解析移到 Worker，再把结果发回来。

数据处理提示（提升速度）

与 Worker 的通信通过 postMessage。对于大型二进制数据，优先使用 transferable objects（例如 ArrayBuffer），这样浏览器可以把内存所有权交给 Worker 而不是复制：

// main thread
worker.postMessage(buffer, [buffer]); // transfers the ArrayBuffer

这对音频缓冲、图像字节或其他大块数据尤其有用。

何时不用 Web Worker

Worker 有开销：额外的文件、消息传递以及不同的调试流程。以下情况可以跳过它们：

• 任务非常微小（毫秒级）且不频繁。\n- 工作需要频繁的 DOM 读/写（Worker 不能访问 DOM）。\n- 需要极低延迟的来回通信；频繁的 postMessage 往返会抵消好处。

一个简单的经验法则

如果一个任务可能引起明显的停顿（通常 ~50ms 以上）且可以表示为“输入 → 计算 → 输出”且不需要 DOM 访问，则通常值得使用 Web Worker。如果主要是 UI 更新，就留在主线程并优化那里。

什么是 Service Worker？

Service Worker 是一种在浏览器后台运行的特殊 JavaScript 文件，充当你站点的可编程网络层。它不在页面本身运行，而是位于你的 Web 应用与网络之间，让你决定在请求资源（HTML、CSS、API 调用、图片）时如何处理。

生命周期基础（注册 → install → activate → control）

Service Worker 有一个独立于任何单个标签页的生命周期：

• Register（注册）：页面告诉浏览器“该站点有一个 Service Worker”（通常从主 JS 中）。\n- Install（安装）：浏览器下载并运行安装步骤，常用于预缓存重要文件。\n- Activate（激活）：新 Worker 接管，通常在关闭旧标签或安全替换旧版本后发生。\n- Control（控制）：一旦激活，它可以在其作用域内“控制”页面并开始拦截请求。

因为它可以随时被停止和重启，要把它当作事件驱动脚本：快速完成工作、把状态存到持久化存储，不要假设它一直在运行。

作用域和源规则（高层）

Service Worker 受限于同源（相同域/协议/端口），并且只能控制其作用域下的页面——通常是 Worker 文件所在的文件夹及其子路径。它们还要求 HTTPS（本地开发可以是 localhost），因为它们能影响网络请求。

常见 API

• Fetch 事件：拦截请求并决定使用网络、缓存还是自定义响应。\n- Cache Storage API：存储并检索缓存响应以支持离线和加速。\n- Clients API：与受控的打开标签/窗口通信并进行管理。

Service Worker 的用途

Service Worker 主要用于位于你的 Web 应用与网络之间。它可以决定何时使用网络、何时使用缓存、何时在后台完成某些工作——且不会阻塞页面。

离线支持（智能缓存）

最常见的工作是通过缓存资源和响应实现离线或“网络差”体验。

一些常见的缓存策略：

• Cache-first：适合静态文件（CSS、JS、Logo）。快速且离线可用。\n- Network-first：适合经常变化的内容（新闻、动态流），离线时回退到缓存。\n- Stale-while-revalidate：立即显示缓存内容，然后在后台刷新以供下次使用。

这通常通过 Cache Storage API 和 fetch 事件处理实现。

更快的重复访问体验

Service Worker 可以通过下列方式提升回访的感知速度：

• 预缓存（Precaching）：在安装期间保存“必须有”的应用文件（通常称为 app shell）。\n- 运行时缓存（Runtime caching）：在用户导航时缓存页面或 API 响应。

结果是更少的网络请求、更快的启动速度，以及在不稳定网络下更一致的表现。

后台功能（取决于支持情况）

Service Worker 可以支持后台功能，例如 推送通知 和 后台同步（各浏览器/平台支持程度不同）。这意味着你可以在页面未打开时仍发送通知或稍后重试失败的请求。

PWA 的构建模块

如果你在构建 渐进式 Web 应用（PWA），Service Worker 是下列功能的核心：

• 可安装性（与 Web App Manifest 配合）\n- 可靠的 离线页面（例如友好的回退页）\n- 用于流畅导航的 app shell 模式

关键差异：Web Worker vs Service Worker

如果只记住一件事：Web Worker 帮助页面在不冻结 UI 的情况下做繁重计算，而 Service Worker 帮助应用控制网络请求并表现得像可安装的应用（PWA）。

它们运行的位置（各自的职责）

Web Worker 用于 CPU 密集型任务——解析大数据、生成缩略图、数值计算——以保证主线程响应。\n\nService Worker 则用于 请求处理和应用生命周期任务——离线支持、缓存策略、后台同步、推送通知。它位于应用与网络之间。

生命周期与“谁拥有它”

Web Worker 通常 与页面/标签页绑定。页面消失时，Worker 通常也会结束（除非使用如 SharedWorker 的特殊情况）。\n\nService Worker 是事件驱动的。浏览器可在处理事件（如 fetch 或 push）时启动它，空闲时再停止。因此它可以在没有打开标签页的情况下运行。

网络访问与控制

Web Worker 无法拦截页面发出的网络请求。它可以执行 fetch()，但不能为站点的其他部分重写、缓存或提供响应。\n\nService Worker 可以通过 fetch 事件拦截网络请求，决定是否使用网络、从缓存返回或使用回退响应。

存储与缓存

Web Worker 不管理 HTTP 缓存。\n\nService Worker 经常使用 Cache Storage API 来存储并提供请求/响应对——这是离线缓存和“瞬时”重复加载的基础。

如何设置它们（高层步骤）

让 Worker 运行主要关乎 运行位置 以及 如何加载。Web Worker 由页面直接创建。Service Worker 由浏览器安装并位于你站点请求的前面。

Web Worker：由页面创建

当页面创建一个 Web Worker 时，它就运行了。你指向一个独立的 JS 文件，并通过 postMessage 通信：

// main.js (running on the page)
const worker = new Worker('/workers/resize-worker.js', { type: 'module' });

worker.postMessage({ action: 'start', payload: { /* ... */ } });

worker.onmessage = (event) => {
  console.log('From worker:', event.data);
};

一个好的心智模型：Worker 文件就是页面可以获取的另一个脚本 URL，但它在主线程之外运行。

Service Worker：注册（一次）并让浏览器安装

Service Worker 必须从用户访问的页面注册：

// main.js
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

注册后，浏览器会处理 install/activate 生命周期。你的 sw.js 可以监听 install、activate 和 fetch 等事件。

为什么 Service Worker 需要 HTTPS

Service Worker 能拦截网络请求并缓存响应。如果允许通过 HTTP 注册，网络攻击者可能替换 sw.js 并控制未来的访问。HTTPS（或开发时的 http://localhost）保护了可影响的脚本和流量。

版本化心态：把 Worker 文件当作可部署的“发布版”

浏览器对 Worker 的缓存与更新方式与普通页面脚本不同。请为更新做好计划：

• 行为改变时更改文件（通常通过部署新的 sw.js/worker 包）。\n- 对于 Service Worker，预期会有“更新”流程：新 Worker 安装，然后在安全时激活。\n- 更改缓存规则时，在激活期间加入清理逻辑以防旧缓存残留。

如果想要更平滑的发布策略，请参见 /blog/debugging-workers 获取早期捕捉更新边缘情况的测试习惯。

在浏览器中调试和测试 Workers

Workers 的失败方式与普通页面 JS 不同：它们在独立上下文运行、有各自的控制台，且可能被浏览器重启。良好的调试流程可以节省大量时间。

Web Worker 调试（DevTools）

打开 DevTools 并查找 worker 特定目标。在 Chrome/Edge 中，你通常会在 Sources 下看到 Workers（或通过“Dedicated worker”条目）并在控制台上下文切换中查看。\n 使用与你在主线程中相同的工具：\n

• 控制台日志：Web Worker 的日志会出现在 DevTools 中，但要确保你在查看正确的上下文。\n- 断点：在 Worker 脚本内设置断点；逐步调试 onmessage 处理器和长时间运行的函数。\n- 性能分析：录制 Performance 跟踪，确认主线程在 Worker 执行重任务时保持响应。

如果消息“丢失”，检查双方：确认你确实调用了 worker.postMessage(...)，Worker 有 self.onmessage = ...，并且消息结构匹配。

Service Worker 调试（Application 面板）

Service Worker 最好在 Application 面板调试：\n

• 检查 registration status、scope 以及 active/waiting/installed 的版本。\n- 使用生命周期控制（如 Skip waiting 和 Unregister）来重置错误状态。\n- 启用 Update on reload 来避免在迭代时追逐陈旧代码。

还要留意控制台中的 install/activate/fetch 错误——这些通常能解释缓存或离线行为为何不工作。

常见陷阱与测试建议

缓存问题是第一大时间消耗点：缓存了错误的文件（或过度缓存）会导致旧的 HTML/JS 留在用户端。测试时尝试 强制重载 并确认实际提供的内容。

为了更真实地测试，使用 DevTools 来：\n

• 模拟 Offline 模式并验证回退页面\n- 应用 网络限速\n- 多次重载以验证 Service Worker 更新与消息处理

如果你在快速迭代 PWA，生成一个干净的基线应用（有可预测的 Service Worker 和构建输出）然后再调整缓存策略，会很有帮助。像 Koder.ai 这样的平台也能用于原型开发：你可以通过聊天提示生成 React 基础应用，导出源码，然后在更紧密的反馈循环里调整 Worker 配置和缓存规则。

安全、隐私与性能注意事项

Workers 可以让应用更流畅、更强大，但它们也改变了代码运行的位置和可访问的内容。快速检查安全、隐私与性能可以避免令人惊讶的 bug 和不满的用户。

安全边界（以及同源为何重要）

Web Worker 与 Service Worker 都受 同源策略 限制：它们只能直接与相同协议/主机/端口的资源交互（除非服务器通过 CORS 显式允许跨域访问）。这防止 Worker 在不知情的情况下从其他站点拉取数据并混入你的应用。

Service Worker 有额外的防护：通常要求 HTTPS（开发时例外为 localhost），因为它们可以拦截网络请求。把它们当作受权代码：保持依赖最小化、避免动态加载可执行代码、并在更改缓存逻辑时小心版本控制以免旧缓存继续提供过时文件。

隐私与用户预期

后台功能应当让用户感觉可预见。推送通知 很强大，但权限提示容易被滥用。

只在有明显收益时请求权限（例如用户在设置中启用了提醒），并解释他们将收到什么。如果你在后台同步或预抓取数据，请用简单语言告知——用户会注意到意外的网络活动或通知。

要注意的性能风险

Worker 并非“零成本”。滥用可能适得其反：

• 消息开销：频繁的 postMessage（尤其带大对象）会成为瓶颈。尽量批处理并使用 transferables。\n- 内存开销：每个 Worker 有自己的内存和启动开销；太多 Worker 会增加 RAM 使用并消耗电池。\n- 缓存膨胀：过度缓存会占用存储。为缓存添加限制并在更新时清理。

优雅降级

并非每个浏览器都支持每项能力（或者用户会阻止权限）。进行特性检测并优雅降级：

if ('serviceWorker' in navigator) {
  // register service worker
} else {
  // continue without offline features
}

目标是：核心功能应仍然可用，“可选增强”（离线、推送、重计算）在可用时再启用。

常见模式：两者一起使用

Web Worker 与 Service Worker 解决不同问题，因此当应用既需要繁重计算又需要快速可靠加载时，它们搭配得很好。一个好的心智模型是：Web Worker = 计算，Service Worker = 网络 + 缓存，主线程 = UI。

模式 1：图像处理 + 离线图库

假设你的应用允许用户编辑照片（缩放、滤镜、去背景）并离线查看图库：

• Web Worker 负责 CPU 密集的工作（解码、变换、生成缩略图），保持滚动和点击流畅。\n- Service Worker 把生成的缩略图和原图缓存到 Cache Storage（或把元数据放到 IndexedDB），在重复访问或离线时立即提供。

这种“先计算再缓存”方法职责清晰：Worker 产生输出，Service Worker 决定如何存储和提供它们。

模式 2：数据同步 + 后台缓存

对于有动态流、表单或离线字段数据的应用：

• Web Worker 可以在后台规范化大 JSON、做差分计算或验证数据而不阻塞 UI。\n- Service Worker 可以缓存 API 响应以加快启动，并在连通性恢复时刷新缓存并（在支持时）协调后台同步。

即使没有完整的后台同步，Service Worker 也能通过在后台更新缓存来提升感知速度，同时为应用提供缓存响应。

保持职责分离

避免混淆角色：

• UI 线程：渲染、用户输入、无障碍、最小状态绑定。\n- Web Worker：纯计算与数据准备（通常通过 postMessage）。\n- Service Worker：请求路由、缓存策略、离线回退。

快速清单：我需要哪一个？

• 任务是 CPU 密集（解析、编码、加密、图像/音频处理）吗？使用 Web Worker。\n- 任务是关于拦截请求、离线行为或缓存吗？使用 Service Worker。\n- 既要保持 UI 流畅又要加快加载/离线？两个都用，但明确边界：计算放 Web Worker，存储/提供放 Service Worker。

FAQ：人们常问的实用问题

Service Worker 能访问 DOM 吗？

不能。Service Worker 在后台运行，与任何页面标签分离，无法直接访问 DOM（页面的 HTML 元素）。

这种隔离是有意的：Service Worker 旨在在没有页面打开时也能工作（例如响应推送事件或提供缓存文件）。因为可能不存在可操作的文档，浏览器把它隔离开来。

如果 Service Worker 需要影响用户可见内容，它会通过消息与页面通信（例如 postMessage），由页面来更新 UI。

我需要 Web Worker 吗，需要先有 Service Worker 吗？

不需要。Web Worker 和 Service Worker 是互相独立的功能。\n\n- Web Worker：当你想把繁重 JavaScript 从主线程移出（例如解析、计算、图像处理）时使用。\n- Service Worker：当你想要网络层能力（离线缓存、拦截请求、后台同步、推送）时使用。

你可以只用其中一个，也可在需要同时计算与离线/网络功能时把它们结合起来。

Workers 在各浏览器的支持情况如何？

在现代浏览器中，Web Workers 广泛支持，通常是安全的“基线”选择。\n\nService Workers 在主流浏览器的新版本中也得到了广泛支持，但有更多要求和边缘情况：\n\n- 需要 HTTPS（开发时可用 localhost）。\n- 某些功能（如推送通知）在不同浏览器/平台上支持度不同。

如果兼容性非常重要，把 Service Worker 的特性当作渐进增强：先构建良好的核心体验，再在可用环境中加入离线/推送等功能。

这会自动让我的站点更快吗？

不会自动变快。\n\n- Web Worker 在你的站点因为主线程上的 CPU 密集型 JS 导致变慢时有帮助。把工作移走可以减少卡顿并提升响应性——但你仍需支付消息传递开销。\n- Service Worker 在站点因网络请求导致慢时有帮助。缓存与智能 fetch 处理可以让重复访问感觉瞬间加载——但错误的缓存策略可能导致内容陈旧。

真正的收益来自于针对具体瓶颈使用合适的 Worker，并在使用前后进行测量。