Web Worker 怎样传输大数组减少复制

我在页面线程里把大数组交给 Web Worker 做解析时，最容易误判的一点是：把数据放进 postMessage() 并不等于把原来的内存直接交过去。普通结构化克隆会生成另一份数据；如果消息里是几十 MB 的二进制内容，复制本身就可能成为卡顿来源。

真正适合这个场景的写法是把底层 ArrayBuffer 同时放进消息对象和第二个参数的 transfer list。这样移动的是缓冲区的所有权，主线程发送完成后不再拥有它。

传输大数组时优先传 TypedArray 或包含它的消息，并在 transfer list 中写入它的 .buffer。传输后，主线程的旧视图会失去底层内存，不能再当作可读写数组使用。

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

关键差别：复制的是视图，移动的是底层 ArrayBuffer

Uint8Array、Int32Array 这类对象是建立在缓冲区之上的视图。视图记录元素类型、偏移量和长度，但真正占用大块内存的是 ArrayBuffer。TypedArray 可以被结构化克隆，却不是可转移对象；它的 .buffer 才是可放入 transfer list 的资源。

还有一个容易忽略的规则：transfer list 只说明哪些资源要移动，并不会自动把资源放进消息。下面两种信息必须对应：消息中能让接收端取得缓冲区，数组参数中声明这个同一个缓冲区要转移。

最小写法：把 buffer 放进 transfer 列表

主线程可以把一个视图作为消息的一部分，同时把视图背后的缓冲区交给 Worker。示例中故意传递 offset 和 length，这样 Worker 不会误把整个底层缓冲区都当成有效区间。

// main.js：把大数组的所有权交给 Worker，发送后不要再使用 view
const worker = new Worker("worker.js", { type: "module" });
const buffer = new ArrayBuffer(16 * 1024 * 1024);
const view = new Uint8Array(buffer, 1024, 4096);

worker.postMessage(
  { buffer, offset: view.byteOffset, length: view.byteLength },
  [buffer], // 中文说明：第二个参数声明移动同一个底层缓冲区
);

// 中文说明：传输完成后原 buffer 已 detached，byteLength 会变为 0
console.log(buffer.byteLength);

// worker.js：接收已经转移所有权的缓冲区，再按元数据重建视图
self.onmessage = (event) => {
  const { buffer, offset, length } = event.data;
  // 中文说明：只读取消息声明的有效区间，避免误处理其他字节
  const input = new Uint8Array(buffer, offset, length);
  const checksum = input.reduce((sum, value) => (sum + value) % 65536, 0);

  // 中文说明：结果很小，直接复制回主线程即可；大块结果也可再次转移
  self.postMessage({ length: input.length, checksum });
};

Worker 取得的是同一块底层内存的所有权，而不是页面线程继续持有的一份共享副本。主线程后续如果需要保留原数据，应在发送前明确复制一份，不能指望 transfer 同时满足“零复制”和“发送端继续修改”这两个互相冲突的目标。

我实际最容易踩到的三个坑

第一，发送后继续读旧视图。转移成功后原 ArrayBuffer 被 detached，相关视图的长度也会变成 0；对它做读取、写入或部分方法调用可能抛出异常。需要继续使用的数据，应在 transfer 前复制，或把后续计算也放到 Worker 中。

第二，只传视图却没有传底层 buffer。把 view 放进消息能让结构化克隆处理它，但把 view 放进 transfer list 并不能代替 view.buffer。传输列表中的对象必须是可转移资源，并且资源还要能从消息对象到达接收端。

第三，忽略 byteOffset。一个视图可能只覆盖底层缓冲区的一段。若 Worker 直接执行 new Uint8Array(event.data.buffer)，就可能把前后的无效字节也纳入处理。把偏移量和有效长度作为消息元数据，是比假设“视图从 0 开始”更稳妥的接口约定。

兼容与取舍：什么时候退回复制

业务代码可以先检测 Worker、postMessage 和 ArrayBuffer 是否存在，再选择转移路径。对于不支持 Worker 的环境，主线程直接处理或保留普通结构化克隆通常比强行模拟所有权移动更可靠。

// feature-check.js：能力不足时回到可读性更好的复制式路径
function sendBytes(worker, view) {
  if (typeof Worker === "undefined" || !(view.buffer instanceof ArrayBuffer)) {
    // 中文说明：没有 Worker 时交给当前线程处理，避免调用不存在的 API
    return processOnMainThread(view);
  }

  // 中文说明：转移后 view 不再归当前线程使用，调用方必须遵守所有权约定
  worker.postMessage({ buffer: view.buffer }, [view.buffer]);
  return undefined;
}

structuredClone(value, { transfer: [buffer] }) 也能表达“克隆消息结构、转移指定资源”，但它仍然会让原缓冲区失去所有权。SharedArrayBuffer 则是共享内存模型，不是 ArrayBuffer 的简单替代；它需要额外的跨线程同步与部署安全条件，不能仅因为想少一次复制就直接换用。

相关问题

问：为什么 transfer list 里不能直接写 Uint8Array？
答：TypedArray 是视图，不是可转移对象；通常把它的 .buffer 放入 transfer list。

问：传输是不是永远零复制？
答：ArrayBuffer 的所有权转移通常可以避免应用层再复制一份，但具体实现细节由浏览器负责，文章不能把它当成所有对象都零复制。

问：主线程还要保留原数组怎么办？
答：在发送前复制，或使用结构化克隆保留独立副本；不要在转移后继续依赖原视图。