从 Web Worker 到 Service Worker：浏览器端多线程的真实用途与工程边界

实际上，这两种工作器虽然都实现了JavaScript的“多线程”，但它们的诞生背景、设计目标和运行机制有着根本性的不同。一个更像是你从主线程“雇佣”的临时计算专家，活干完（页面关闭）就解散；另一个则像是浏览器为你站点配备的常驻网络管家，即使你不在家（关闭标签页），它也能帮你处理信件（网络请求）和打理仓库（缓存）。

Web Worker：主线程的CPU卸载器

当你的页面因为解析一个巨大的JSON、应用一个复杂的Canvas滤镜，或者运行一段机器学习推理而变得卡顿时，Web Worker就该出场了。它的核心使命非常单纯：把消耗CPU的计算任务从负责渲染和交互的主线程上移走。

创建一个Web Worker很简单，但它一出生就带着几个关键限制，这些限制恰恰定义了它的能力边界：

• 生命周期与页面绑定：它由页面脚本通过new Worker()创建，页面关闭，Worker随之终止。它无法独立存活。
• 无权直接操作UI：无法访问DOM、window或document对象。这意味着任何计算结果必须通过消息传回主线程，由主线程来更新界面。
• 通信成本明确：与主线程通过postMessage通信，传递的数据会经过“结构化克隆”，这意味着函数、DOM节点等不可序列化的对象传不了，且大数据量的传递会有拷贝开销。

一个典型的适用场景是图像处理。假设你在做一个图片编辑的Web应用，用户上传照片后需要实时应用“高斯模糊”滤镜。在主线程做像素级循环计算肯定会阻塞UI响应。这时，把图像数据（比如ImageData）发送给Web Worker，在Worker里完成密集计算，再将处理后的数据传回来，界面就能保持流畅。

// 主线程
const imageWorker = new Worker('image-processor.js');
canvasElem.onchange = (e) => {
  const imageData = getImageDataFromCanvas();
  imageWorker.postMessage({ cmd: 'applyBlur', data: imageData });
};

imageWorker.onmessage = (e) => {
  const processedData = e.data;
  updateCanvasWithData(processedData); // 主线程更新DOM
};

// image-processor.js (Worker线程)
self.onmessage = function(e) {
  if (e.data.cmd === 'applyBlur') {
    const rawData = e.data.data;
    const result = applyHeavyGaussianBlur(rawData); // 耗时计算
    self.postMessage(result);
  }
};

需要注意的是，Web Worker虽然能使用fetch发起网络请求，但它只是一个请求的“发起者”，无法拦截、修改或缓存其他请求。这是它与Service Worker最显著的区别之一。

Service Worker：浏览器级的网络代理与状态管理者

Service Worker的出现，主要不是为了解决CPU计算问题，而是为了赋予Web应用更强的网络控制能力和离线生命力。它是构建PWA（渐进式Web应用）的基石。

你可以把Service Worker理解为一个安装在用户浏览器中、为你特定站点服务的本地代理服务器。它的核心超能力是拦截和处理网络请求。一旦注册并激活，它就能监听作用域内所有页面的fetch事件。

它的几个关键特性彻底改变了Web应用的玩法：

• 独立且持久的生命周期：通过navigator.serviceWorker.register()注册后，其生命周期由浏览器管理，与单个页面脱钩。即使所有相关标签页都关闭，Service Worker仍然可以运行（例如处理后台同步或推送通知），直到浏览器出于节能或内存原因将其终止。
• 网络请求拦截器：这是其最核心的功能。可以缓存HTML、CSS、JS、图片等任何资源，实现离线访问；可以修改请求头或响应内容；甚至可以在网络不可用时返回自定义的离线页面。
• 作用域覆盖多个页面：一个Service Worker可以控制其注册路径下的所有标签页。这使得跨页面状态同步和资源共享成为可能。

一个常见的工程实践是用Service Worker实现静态资源的版本化缓存和离线回退。下面是一个简化的缓存优先策略示例：

// sw.js
const CACHE_NAME = 'my-site-cache-v1';
const urlsToCache = ['/', '/styles/main.css', '/script/app.js'];

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(urlsToCache))
  );
});

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // 缓存命中则返回，否则尝试网络请求
        return response || fetch(event.request);
      })
  );
});

然而，Service Worker并不适合执行长时间的CPU密集型任务。因为浏览器会监控其运行，长时间的任务可能导致Worker被强行终止，以保护用户设备的电池和隐私。

关键差异对比与选型指南

为了更清晰地做出技术选型，我们可以从几个维度对两者进行对比：

基于上表，我们可以得出一些清晰的选型原则：

• 如果你的问题是“主线程太忙，界面卡了”，首先考虑Web Worker。
• 如果你的问题是“想让应用离线可用”、“优化重复资源的加载速度”、“在后台静默更新数据”，那么你应该研究Service Worker。
• 记住，它们不能互相替代，但可以在一个应用中共存，各司其职。

实战中的协同与注意事项

在复杂的应用中，Web Worker和Service Worker可能需要协同工作。一个经典的协同模式是：Service Worker处理推送通知，但推送负载中的数据需要复杂解析或解密，这个计算任务就交给Web Worker。

由于两者不能直接通信，页面必须充当“中转站”：

1. Service Worker收到推送（push事件）。
2. Service Worker向所有客户端页面发送消息（self.clients.matchAll().then(...postMessage)）。
3. 页面接收到消息，创建或唤醒一个Web Worker，将需要处理的数据传给它。
4. Web Worker完成计算，将结果传回页面。
5. 页面用结果更新UI或进行下一步操作。

在引入这两种工作器时，还需要警惕一些常见的“坑”：

• Web Worker的通信开销：频繁发送大量数据（如高清图片的像素数据）会带来序列化和反序列化的成本，有时甚至可能抵消多线程带来的收益。对于极大数据集，可以考虑使用Transferable Objects来转移所有权，避免拷贝。
• Service Worker的更新机制：Service Worker的更新遵循“新版本安装，旧版本仍运行，直到所有页面关闭”的流程。这要求你的缓存策略必须能够优雅处理版本过渡，否则用户可能长期卡在旧版本上。使用cache.delete()清理旧缓存是activate事件中的常见操作。
• 调试复杂性：两者都在独立线程运行，调试不如主线程直观。Chrome DevTools的“Application”面板提供了专门查看和管理Service Worker及缓存的面板，而“Sources”面板可以调试Web Worker脚本，善用这些工具能节省大量时间。

总结：在正确的边界内解决问题

理解从Web Worker到Service Worker的差异，本质上是理解浏览器将“并发能力”赋予前端开发者的两种不同维度：一种是计算能力的横向扩展，用于解决性能瓶颈；另一种是网络与控制能力的纵向深化，用于增强应用的能力与可靠性。

成熟的工程决策始于对工具本质的洞察。下次当你面临优化挑战时，不妨先问自己：这个问题的核心是CPU等待，还是网络等待？状态是否需要跨页面甚至离线持久化？回答清楚这些问题，你自然就能在Web Worker和Service Worker之间做出明确、高效的选择，让浏览器的多线程能力真正为你的产品体验服务，而不是引入新的复杂度。