Web Worker 传大数据为何卡顿：复制与 Transferable 对比

Web Worker 传大数据出现卡顿，通常不是 Worker 失效，而是消息发送时仍在做 structured clone。普通对象、数组和 TypedArray 默认会被序列化并在另一侧生成副本；当数据达到数 MB 甚至更大时，复制本身就会占用主线程时间。若数据是一次性消费的二进制块，可以把底层 ArrayBuffer 放进 transfer list，让资源所有权转给 Worker。

复制和 Transferable 的差别在哪里

worker.postMessage(data) 默认使用 structured clone。它能处理循环引用，也不会让主线程和 Worker 共享同一个普通对象；代价是复杂对象需要遍历和复制。Transferable 则是把某些对象拥有的底层资源移动到接收端，ArrayBuffer 是最常见的选择。

因此不要只看“代码放进 Worker 了没有”，还要看数据跨线程时采用哪种语义。字符串、配置对象和小数组直接复制更简单；大块二进制数据若在发送后不再由主线程使用，就适合转移。

用 ArrayBuffer 传递大数据

下面的例子把 8MB 数据交给 Worker。消息体里携带同一个 buffer，第二个参数也必须传入同一个对象：

const worker = new Worker("worker.js");
const bytes = new Uint8Array(8 * 1024 * 1024);

// 给示例数据写入一个可识别的首字节，便于 Worker 侧处理
bytes[0] = 42;
// 发送视图背后的 ArrayBuffer，并转移它的所有权
worker.postMessage({ buffer: bytes.buffer }, [bytes.buffer]);
// 发送后 bytes.buffer 已被 detach，主线程不要再读取它

Worker 端接收的是新的 ArrayBuffer 对象，可以按业务需要重新建立视图：

self.onmessage = (event) => {
  const buffer = event.data.buffer;
  // 接收端重新建立视图，避免把 ArrayBuffer 当成可索引数组
  const bytes = new Uint8Array(buffer);
  // 这里执行计算；示例只返回长度，实际项目可返回摘要或结果块
  self.postMessage({ byteLength: bytes.byteLength, firstByte: bytes[0] });
};

发送后为什么不能继续读原来的 buffer

转移的核心是所有权变化，不是“复制一份再发过去”。发送端的 ArrayBuffer.byteLength 会变成 0，原来的 TypedArray 视图也不再指向可用资源。若后续还要展示、重试或再次发送，就要在转移前保留副本，或者改用复制语义。

如何选择并避免常见坑

第一，transfer list 只声明转移对象，不会凭空把对象放进消息；对象必须同时出现在消息体中。第二，不能把 Uint8Array 本身放进 transfer list，应传 Uint8Array.buffer。第三，转移后不要在发送端继续调用视图读写方法。第四，Transferable 只减少数据搬运成本，Worker 内部的解析、解码和计算仍然需要时间，不能把所有卡顿都归因于复制。

相关问题

为什么只写 transfer list 还收不到数据？

因为 transfer list 只指定哪些资源改用转移语义，资源仍必须嵌在消息体中，通常写成 { buffer } 并把同一个 buffer 放入数组。

Transferable 会不会让两边同时拥有数据？

不会。它转移的是所有权，发送端资源会 detach；需要两边各自保留内容时，应显式复制或重新生成一份。

什么时候不该使用 Transferable？

小对象、发送后仍要复用的数据，以及需要双方长期共享并发状态的数据，都不适合为了“更快”强行转移。