前端 Web Worker 移出计算 怎样处理

我第一次把前端计算移到 Web Worker，是因为一个看起来并不大的数据清洗任务开始拖慢输入框。真正需要先判断的不是“能不能创建 Worker”，而是这段工作是否值得承担线程通信、数据复制和生命周期管理的成本。结论是：纯计算、耗时稳定、输入输出可以序列化的任务适合移出主线程；需要直接改 DOM、依赖窗口对象，或数据量很小的任务，继续留在主线程反而更简单。

官方资料：https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

把 Worker 当成一个有消息边界的计算模块，而不是把主线程代码原样搬过去。先缩小消息，再决定是否转移 ArrayBuffer，最后明确谁负责终止 Worker。

先判断哪些计算值得移出去

Dedicated Worker 运行在不同的全局上下文中，不能直接操作页面 DOM；主线程和 Worker 通过 postMessage() 交换数据。适合移出的通常是大数组遍历、文本解析、压缩前处理、哈希计算、图片像素变换等“输入明确、输出明确”的工作。

我会先问三个问题：

• 计算期间是否需要读取或修改 document、window 或页面组件实例？如果需要，就把 DOM 读写留在主线程，只把纯数据计算交给 Worker。
• 一次任务的计算时间是否明显长于一次消息往返？数据很小、任务很短时，复制和调度成本可能抵消收益。
• 输入是否能变成结构化可克隆的数据？函数、DOM 节点和部分带原型状态的对象不能直接按原样传递。

用最小消息协议承载计算

不要把页面状态整个对象传给 Worker。我更倾向于定义一个小协议：请求带 type、任务标识和纯数据，结果带同一个任务标识、状态和结果。这样主线程可以把结果对应回正确的输入，也不会把组件、事件对象或无关字段带进复制过程。

const worker = new Worker("./worker.js", { type: "module" });

// 只发送任务需要的纯数据，避免把页面状态和 DOM 引用带进消息。
worker.postMessage({
  type: "count-tags",
  requestId: "req-17",
  values: ["go", "web", "go"]
});

// 主线程只处理结果，不让 Worker 直接修改页面。
worker.addEventListener("message", (event) => {
  const message = event.data;
  if (message.requestId !== "req-17") return;
  if (message.ok) {
    document.querySelector("#result").textContent = String(message.count);
  } else {
    document.querySelector("#error").textContent = message.error;
  }
});

// Worker 是独立资源，页面销毁或任务取消时要释放它。
window.addEventListener("pagehide", () => worker.terminate());

// worker.js
self.addEventListener("message", (event) => {
  const { type, requestId, values } = event.data;
  if (type !== "count-tags" || !Array.isArray(values)) {
    // 用结构化错误返回给主线程，避免把异常对象直接当协议。
    self.postMessage({ requestId, ok: false, error: "参数格式不正确" });
    return;
  }

  // 计算只依赖传入数组，不访问 document 或 window。
  const count = values.filter((value) => value === "go").length;
  self.postMessage({ requestId, ok: true, count });
});

这里的关键不是代码量，而是边界：页面负责输入和展示，Worker 负责纯计算，消息负责把两侧连接起来。Worker 内可以使用不少通用 Web API，但不能把它当成拥有页面 DOM 的第二个窗口。

普通数据复制，大块二进制再考虑转移

postMessage() 默认使用结构化克隆，接收端得到的是可用的副本。对于配置对象、短数组和小段文本，这种方式最容易维护。不要看到“异步”就默认上 SharedArrayBuffer；共享内存会增加同步、可见性和部署条件的复杂度，通常不是第一步。

如果输入是大型二进制数据，可以把 ArrayBuffer 放进消息，同时放入 transfer 列表：

const worker = new Worker("./worker.js", { type: "module" });
const bytes = new Uint8Array(1024 * 1024 * 8);

// 转移的是底层 ArrayBuffer；转移后主线程不再拥有这段内存。
worker.postMessage(
  { type: "scan-bytes", buffer: bytes.buffer },
  [bytes.buffer]
);

// 转移完成后，原视图的 byteLength 会变成 0，不能继续读取它。
console.log(bytes.byteLength);

转移不是“复制得更快”，而是把资源所有权交给另一侧。最容易踩的坑是只把 ArrayBuffer 写进 transfer 列表，却没有把它放进消息对象；这样资源会被移走，但接收端拿不到它。发送端也要在转移后丢弃旧视图，不能继续把它当作有效缓存。

把成功、业务失败和 Worker 错误分开

一个健壮的协议至少要区分三种情况：计算得到的业务结果、输入不合法造成的业务失败，以及脚本加载或运行异常造成的 Worker 级错误。主线程可以同时监听 message、messageerror 和 error，而 Worker 内部则把可预期问题转成普通结果消息。

const worker = new Worker("./worker.js", { type: "module" });

// 业务协议错误由 message 统一处理，便于界面展示。
worker.addEventListener("message", ({ data }) => {
  if (data.ok) {
    renderResult(data.value);
    return;
  }
  renderError(data.error || "计算失败");
});

// 无法反序列化消息时，通常要检查传入值是否可结构化克隆。
worker.addEventListener("messageerror", () => {
  renderError("消息无法被接收端解析");
});

// 脚本加载失败或运行时抛错时，重建 Worker 前先记录上下文。
worker.addEventListener("error", (event) => {
  event.preventDefault();
  renderError("Worker 脚本发生错误");
});

复用 Worker，但给它清晰的退出边界

短任务可以按任务创建 Worker，长列表或连续导入更适合复用一个 Worker，避免频繁创建脚本上下文。复用时要给请求分配 ID，并决定取消策略：如果计算不能中断，就在结果回传时丢弃过期 ID；如果必须立即停止，就调用 terminate() 并重新创建实例。

我实际更看重“谁拥有 Worker”：页面控制器或组件应负责创建、监听和销毁，业务函数只负责提交任务。页面切换、组件卸载和用户取消都要走同一条清理路径，避免 Worker 继续持有闭包和大数组。

一张表判断是否适合迁移

常见误区与最终判断

第一，Worker 不是自动加速器；通信本身有成本。第二，转移 ArrayBuffer 后，原对象失效是所有权变化，不是浏览器异常。第三，Worker 不能直接更新页面，结果回传后仍由主线程渲染。第四，异常监听不能替代消息协议，业务失败仍应返回可识别的数据结构。

如果你的任务能被拆成“主线程准备纯数据—Worker 计算—主线程展示”，就可以从一个最小 Dedicated Worker 开始；先用普通结构化克隆跑通协议，只有大块二进制复制成为瓶颈时，再引入 ArrayBuffer 转移。这样迁移的收益和代价都更容易观察。

相关问题

• Worker 能直接修改页面元素吗？不能，应把结果发回主线程后再更新 DOM。
• ArrayBuffer 转移后还能复用原来的 Uint8Array 吗？不能，原视图所依附的缓冲区已失去所有权。
• 一个任务很短也要创建 Worker 吗？不建议，先比较计算时间与消息和创建成本。