Transferable objects 怎样转移 ArrayBuffer

把较大的二进制数据交给 Worker 时，如果仍按普通对象复制，内存和耗时都会随数据量增长。Transferable objects 的做法是把 ArrayBuffer 的所有权转给接收上下文：发送端的缓冲区会变成 detached，接收端继续持有这块数据。关键写法是让缓冲区同时出现在消息对象和 transfer list 中。

先分清复制和转移解决的是两类问题

结构化克隆会为接收方创建一份独立值，适合双方都要继续使用数据的场景。转移则改变所有权：资源从发送上下文移动到接收上下文，原来的 ArrayBuffer 失去可用的数据存储。它适合“大块数据只需要被下一方接管”的场景，例如主线程把解码输入交给 Worker。

这里不要把“transfer list”理解成额外的数据参数。它只是声明哪些可转移对象要移动；对象本身仍要出现在消息数据中，否则接收方没有可读取的字段，而发送方仍会承担 detached 的结果。

把 ArrayBuffer 放进消息和 transfer list

最小配方是下面这对主线程与 Worker 片段。消息对象里的 input 让 Worker 能拿到缓冲区，第二个参数里的 buffer 则声明所有权转移：

// main.js
const worker = new Worker("worker.js", { type: "module" });
const bytes = new Uint8Array([10, 20, 30, 40]);
const buffer = bytes.buffer;

// input 负责携带数据，transfer list 负责移动 ArrayBuffer 的所有权。
worker.postMessage({ input: buffer }, [buffer]);

// 转移后发送端不再拥有这块存储；这里只做状态提示，不再读取内容。
console.log("buffer 已交给 Worker");

// worker.js
self.onmessage = (event) => {
  // 接收方从消息对象取得已经转移过来的 ArrayBuffer。
  const input = event.data.input;
  const view = new Uint8Array(input);

  // 这里由 Worker 独占这块缓冲区，示例只计算一个简单结果。
  const total = view.reduce((sum, value) => sum + value, 0);
  self.postMessage({ total });
};

这一段最容易写错的是把 bytes 放进 transfer list。TypedArray 可以被结构化克隆，但它本身不是 transfer list 的条目；要转移它所指向的内存，应使用 bytes.buffer。转移完成后，原来的视图也失去可用的底层存储。

关键 JavaScript 关系：视图跟着 buffer 走

Uint8Array 只是对一段 buffer 的访问窗口，包含偏移量、长度和元素类型等视图信息。所有权转移针对的是 ArrayBuffer，不是针对这扇窗口单独复制一份内存。

因此代码设计上要先决定谁是最后一个使用者：

structuredClone 怎样移动嵌套对象里的缓冲区

不经过 Worker 时，可以用 structuredClone 搭配 transfer 选项。它会克隆对象的结构，同时把清单中的 ArrayBuffer 移到结果对象里：

const source = {
  name: "packet",
  payload: new ArrayBuffer(16),
};
const sourceView = new Uint8Array(source.payload);
sourceView[0] = 7;

// transfer 只列出真正要移动的 ArrayBuffer。
const moved = structuredClone(source, {
  transfer: [source.payload],
});

// moved.payload 继续拥有数据；source.payload 已经 detached。
const movedView = new Uint8Array(moved.payload);
console.log(movedView[0]); // 7

如果只是写成 structuredClone(source)，结果是普通克隆，原缓冲区仍可用；加上 transfer 后，语义变成“结果对象接管，源对象放弃”。这也是避免无意修改发送端数据的一种明确所有权表达。

变体和兼容坑要一起处理

• 重复转移：已经 detached 的 ArrayBuffer 不能再次作为有效转移对象；要把所有权交接集中在一个边界上。
• 视图长度：转移前保存的 Uint8Array 不会替你创建第二块内存，转移后不要把它当成仍可读写的业务缓存。
• SharedArrayBuffer：它的语义是共享内存，不是把所有权从一侧交给另一侧；不要用普通 ArrayBuffer 的 transfer list 规则套用。
• 跨窗口消息：如果使用 window.postMessage，要给出明确的 targetOrigin，不要把敏感数据发送到任意来源。
• 浏览器差异：目标环境需要支持对应的 Worker、结构化克隆和 Transferable objects；如果要兼容旧环境，应准备复制数据或其他降级策略，而不是假设 transfer 一定可用。

一份可复用的完整片段

最后把规则压缩成一个可复用的发送函数：调用方明确传入 buffer，函数只负责一次交接；交接之后由接收方继续使用，发送方不再保留隐含引用。

function sendBufferToWorker(worker, buffer, meta = {}) {
  // 要求调用方确认 buffer 是本次交接的唯一所有者。
  if (!(buffer instanceof ArrayBuffer)) {
    throw new TypeError("只接受可转移的 ArrayBuffer");
  }

  // 把 buffer 放在 payload 中，同时在 transfer list 中声明所有权移动。
  worker.postMessage({ meta, buffer }, [buffer]);
}

const worker = new Worker("worker.js");
const payload = new ArrayBuffer(1024);
sendBufferToWorker(worker, payload, { kind: "binary" });

判断这段代码是否适合你的场景，只要问三个问题：发送端是否真的不再需要这块内存、消息对象是否携带了同一个 buffer、接收端是否能在自己的上下文中完成后续处理。三个答案都明确时，Transferable objects 才是在减少复制，而不是把生命周期问题藏起来。

常见问题

为什么不能把 Uint8Array 直接写进 transfer list？

因为 TypedArray 是可序列化的视图，不是 Transferable objects 条目。应把它的 buffer 放进清单，同时让消息或克隆输入包含该 buffer。

转移后还能读取原来的 ArrayBuffer 吗？

不能把它当作可用数据继续读写。转移后源端被 detached，后续应只使用接收方持有的缓冲区。

什么时候不要使用转移？

当发送端和接收端都需要继续使用各自的数据副本时，不要交出所有权，使用普通结构化克隆更符合语义。