Web Workers 传递大型 ArrayBuffer 如何避免复制：Transferable 与引用失效排查

把 32MB 或更大的二进制数据交给 Web Worker 时，普通的结构化克隆可能带来一次额外复制；如果把同一个 ArrayBuffer 放进 transfer 列表，则所有权会转移给 Worker，主线程原来的缓冲区会被分离。排查这类问题的关键不是猜“有没有复制”，而是发送前后检查 byteLength，并把失败消息单独接住。

需要跨线程交接大块二进制数据时，把实际发送的 ArrayBuffer 同时放进消息和 transfer 列表；发送后不要再使用原视图，改为等待 Worker 返回结果。

发送后引用失效，先看 byteLength

线上最容易误判的症状是：postMessage 已经调用成功，但后面的代码读取视图时出现异常，或者业务日志看到缓冲区长度变成了 0。这不是 Worker 把数据“清空”了，而是 Transferable 的所有权已经发生转移。

const worker = new Worker("worker.js", { type: "module" });
const buffer = new ArrayBuffer(1024 * 1024);
const view = new Uint8Array(buffer);
view[0] = 42;

console.log("发送前", buffer.byteLength); // 1048576
worker.postMessage({ buffer }, [buffer]);
console.log("发送后", buffer.byteLength); // 0

这里的 worker.postMessage 同时收到了消息对象和 transfer 列表。ArrayBuffer 是被转移的资源，发送成功后原 buffer 进入 detached 状态；原来的 view 也不能再当作有效数据源。把发送后的对象继续塞进缓存、重复发送或创建新视图，都会把问题扩大。

诊断时先保留发送前的长度和首字节，再在下一行读取 byteLength。如果发送前不是 0、发送后是 0，说明交接确实发生了；如果发送后仍有长度，检查是不是忘记把 buffer 放进第二个参数。

把大块数据安全交给 Worker

生产代码可以把“发送后不再使用原引用”写成明显的边界。主线程只负责创建数据、转移所有权和等待结果；Worker 接收后用新的 Uint8Array 视图读取内容。

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

worker.onmessage = ({ data }) => {
  console.log("Worker 返回", data.size, data.firstByte);
};

worker.addEventListener("messageerror", (event) => {
  console.error("消息无法反序列化", event);
});

const payload = new Uint8Array(32 * 1024 * 1024);
payload[0] = 42;
worker.postMessage({ buffer: payload.buffer }, [payload.buffer]);

self.onmessage = ({ data }) => {
  const payload = new Uint8Array(data.buffer);
  self.postMessage({ size: payload.byteLength, firstByte: payload[0] });
};

这段链路里，Uint8Array 只是访问内存的视图，真正进入 transfer 列表的是它的 ArrayBuffer。postMessage 发出后，主线程不要再读取 payload；worker.onmessage 只处理 Worker 返回的结果，messageerror 则负责记录无法反序列化的异常路径。

为什么有时看起来仍然像“复制”

只传视图，不传底层缓冲区

Uint8Array 本身不是要放入 transfer 列表的资源。可传的是 payload.buffer，而且它还必须作为消息中的字段出现。下面的写法会让 transfer 列表与消息内容脱节，不能得到接收端可用的缓冲区：

worker.postMessage({ kind: "bytes" }, [payload.buffer]);

修复方式是把同一个对象挂到消息上：worker.postMessage({ buffer: payload.buffer }, [payload.buffer])。如果业务需要保留主线程副本，就不要转移原缓冲区，先明确复制成本，再传一个副本。

把发送后的 payload 当作可复用缓存

Transferable 的收益来自所有权转移，所以“发送后继续复用”的设计本身就不成立。可以在发送前把状态改成 in-flight，等 worker.onmessage 返回后再创建下一块缓冲区；不要试图把已分离的原引用恢复成可写对象。

失败时如何回退和确认告警

先把发送动作包在一个小函数里，记录长度、任务编号和发送结果。注意：postMessage 返回值本身不是业务完成信号，真正的完成仍由 Worker 回传。

function sendBytes(worker, payload, jobId) {
  const before = payload.byteLength;
  if (before === 0) throw new TypeError("payload 已经不可用");

  worker.postMessage({ jobId, buffer: payload.buffer }, [payload.buffer]);
  return { jobId, transferred: before, detached: payload.byteLength === 0 };
}

当 detached 不是 true 时，先检查浏览器运行路径和调用参数；当 messageerror 触发时，保留任务编号并走失败队列。若业务不能接受转移后的引用失效，回退到不带 transfer 的结构化克隆，但要在性能监控中单独标出这条路径。

复盘时只保留三项证据

• 发送前后的 ArrayBuffer.byteLength，证明是否发生所有权转移。
• 消息对象是否确实包含 buffer，以及 transfer 列表是否引用同一个底层对象。
• worker.onmessage 和 messageerror 的任务编号，区分成功回传与反序列化失败。

这样处理后，复制成本、引用失效和接收失败会被分成三条可验证的证据链。下一次再遇到“Worker 收到了数据但主线程读不到”的问题，先看长度和所有权，再决定是否需要调整缓存或回退策略。

相关问题

Transferable 会不会把数据复制两份？

对 ArrayBuffer 的所有权转移不要求发送方继续持有原内存，因此通常避免了常规结构化克隆的那次数据复制；但业务如果先手动复制一份，复制成本仍然存在。

为什么 transfer 列表里的对象还要出现在消息里？

列表说明哪些资源要移动，消息对象才决定接收端从哪里取得这些资源。只列出而不挂载，接收端没有可读取的字段。

Worker 处理完成后能把 buffer 传回来吗？

可以。Worker 可以在新的 postMessage 调用中把收到的 ArrayBuffer 再转移回主线程，但每次转移都会改变当前持有方，仍需遵守“发送后不再使用原引用”的边界。

小结

Web Worker 的大数据优化不是给 postMessage 加一个参数就结束了：消息字段、transfer 列表和发送后的对象生命周期必须一起设计。用 byteLength 验证所有权变化，用 onmessage 接收完成，用 messageerror 接住失败，问题就能从“感觉像复制”变成可以复查的运行证据。