Web Worker 里怎么安全传大对象：Transferable、结构化克隆与内存回收

Web Worker 适合把压缩、解析和文件切片这类重活移出主线程，但数据怎么送过去，往往比启动 Worker 更容易埋坑。对几十 MB 的 ArrayBuffer 来说，直接 postMessage(buffer) 默认走结构化克隆，会产生一份副本；把同一个缓冲区放进 transfer list，则是转移所有权，发送完成后主线程的原缓冲区会进入 detached 状态。两种方式都能工作，区别在于内存峰值、发送后的对象还能不能继续使用，以及代码是否明确了所有权边界。

需要把大块二进制数据交给 Worker 处理时，优先考虑 Transferable；需要发送后继续读取原对象，才保留结构化克隆。无论选哪种，都要在发送前后检查字节长度和对象生命周期。

先把两种传递方式放进同一个实验

先用一个 16 MB 的缓冲区做小实验，避免一上来就拿真实文件排查。下面的 Worker 只负责回传长度，主线程分别测试不带 transfer list 和带 transfer list 的调用。

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

function makeBuffer() {
  return new ArrayBuffer(16 * 1024 * 1024);
}

const cloned = makeBuffer();
console.log('before clone:', cloned.byteLength); // 16777216
worker.postMessage({ kind: 'clone', buffer: cloned });
console.log('after clone:', cloned.byteLength);  // 仍然可读

const transferred = makeBuffer();
console.log('before transfer:', transferred.byteLength); // 16777216
worker.postMessage({ kind: 'transfer', buffer: transferred }, [transferred]);
console.log('after transfer:', transferred.byteLength);  // 0

// worker.js
self.onmessage = ({ data }) => {
  const { kind, buffer } = data;
  self.postMessage({ kind, receivedBytes: buffer.byteLength });
};

这里的关键不是日志里的数字，而是发送方能否继续访问原对象。结构化克隆完成后，cloned 仍然拥有自己的内存；Transferable 完成后，transferred 只是一个失去底层存储的对象。后续再创建 new Uint8Array(transferred)，就应该视为程序错误，而不是“数据偶尔为空”。

Transferable 到底转移了什么

postMessage(message, transferList) 的第二个参数表达的是所有权交接。对 ArrayBuffer 来说，Worker 接收的是原来的底层存储，主线程不再拥有这块存储。常见可转移对象还包括 MessagePort、OffscreenCanvas 等，但普通数组、普通对象和字符串并不会因为放进列表就突然变成零拷贝。

这也是为什么 transfer list 要单独写出来。下面的写法把业务消息和所有权交接放在一起，读代码的人能立刻看出发送后哪些变量不能再碰：

const payload = new Uint8Array(fileSlice).buffer;
worker.postMessage(
  { type: 'decode', payload },
  [payload]
);

// 从这里开始，payload.byteLength === 0。
// 不要把 payload 再放进缓存，也不要交给另一个发送流程。

如果需要传递的是 Uint8Array，通常放进 transfer list 的是它的 .buffer，但要确认这个视图确实独占那块缓冲区。一个视图可能只覆盖共享缓冲区的一小段，或者和其他视图共用同一个 ArrayBuffer；转移后，所有依赖这个 buffer 的视图都应当被当作不可用。

消息流水线里最容易漏掉的三个检查点

发送前确认切片边界

大文件一般不会一次性全部转移。切片时记录 offset、length 和序号，Worker 回传结果时带上同一个序号。不要用“收到的字节数等于文件总大小”作为唯一成功条件，那会掩盖最后一片长度或重复发送的问题。

发送后立刻切断旧引用

转移成功后，把旧变量从待处理队列中移除；如果缓存对象还挂着它，垃圾回收器仍然要等引用断开。可以让队列只保存元数据和序号，不保存已经交接出去的 buffer：

const pending = new Map();

function sendChunk(id, bytes) {
  const buffer = bytes.buffer;
  pending.set(id, { length: bytes.byteLength });
  worker.postMessage({ id, buffer }, [buffer]);
}

worker.onmessage = ({ data }) => {
  const meta = pending.get(data.id);
  if (!meta || meta.length !== data.receivedBytes) {
    throw new Error('chunk length mismatch');
  }
  pending.delete(data.id);
};

处理结束后结束无用 Worker

Worker 本身也可能持有模块级缓存、消息监听器或未完成的 Promise。一次性任务完成后调用 worker.terminate()，长驻 Worker 则要设计明确的清空消息和关闭协议。看到主线程对象长度变成 0，并不代表整个任务已经释放完毕。

结构化克隆什么时候反而更合适

如果发送方还要重试、预览或把同一份数据交给两个消费者，结构化克隆更容易维护。它付出的代价是复制时间和内存峰值；这时可以改成小批量消息、降低并发窗口，或者让一个 Worker 负责分发，而不是盲目把每份数据都复制到多个 Worker。

选择 Transferable 也不等于自动更快。数据如果只有几 KB，复制成本很低，所有权切换带来的状态复杂度反而不划算。真正值得转移的通常是二进制大块数据，并且发送后不再需要原对象的场景。

用浏览器工具核对内存，而不是只看一条日志

调试时先固定输入大小和消息并发数，再在 Performance、Memory 或浏览器任务管理器中观察一轮完整流水线。重点看三个时刻：发送前的峰值、Worker 正在处理时的占用、所有消息完成并清空引用后的回落。不同浏览器的回收时机不完全一致，所以不要把一次 GC 没有立刻发生当作泄漏证据。

可以额外记录未完成序号数量、Worker 是否仍有待处理消息、缓存 Map 的大小和 Worker 是否已终止。若这些业务指标都归零，内存仍持续增长，再进一步抓取堆快照，寻找闭包、事件监听器或全局缓存留下的引用。

常见误区与排查顺序

• 把 Transferable 当成复制。发送后继续读取 detached buffer，得到异常或空数据时，先查 transfer list 和所有权设计。
• 只转移视图，不检查底层 buffer。确认多个 TypedArray 是否共享同一个 ArrayBuffer，否则一个切片可能让其他业务视图一起失效。
• 把内存峰值当成泄漏。先等消息队列清空、引用删除和合理的 GC 时机，再用堆快照对比 retained size。
• 重复发送同一个已转移 buffer。给每个切片分配唯一序号，在状态表中区分 created、sent、done，避免重试逻辑把 detached 对象再次入队。

把所有权边界写成可验收的约定

团队协作时，接口文档至少写清四件事：谁创建 buffer，谁在发送后拥有它，Worker 回传的是结果还是原 buffer，以及失败时由谁负责重试。测试中覆盖空切片、最后一片不足固定大小、Worker 提前终止和重复消息，才能让 Transferable 的性能收益不变成偶发数据错误。

相关问题

Transferable 会不会把数据复制一份再发送？

对可转移的底层存储，语义是所有权转移，不是让发送方继续保留一份可读副本。发送完成后要按 detached 对象处理。

普通 JSON 对象需要放进 transfer list 吗？

不需要。普通对象走结构化克隆；只有支持转移语义的对象才适合放进 transfer list。

为什么内存没有马上降下来？

浏览器回收不是同步动作。先确认消息已完成、缓存和监听器引用已清理、一次性 Worker 已终止，再用多次堆快照判断是否存在持续保留。

小结

结构化克隆换来更简单的共享语义，Transferable 换来更低的复制和峰值成本，但代价是发送方立即失去底层内存。把 transfer list、序号状态、引用清理和 Worker 关闭协议一起设计，才能让大对象传输既快又可排查。