Web Workers 怎样用 transferable 减少数组复制

向Web Worker发送TypedArray时，把它的ArrayBuffer加入postMessage第二个参数的转移列表，例如worker.postMessage({data: values}, [values.buffer])。这样可转移底层缓冲区资源，减少这部分数据复制；成功转移后发送端原缓冲区会分离，不能继续把原视图当作有效数组使用。

参考文档地址：https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects

现象：大数组发给 Worker 后仍有复制成本

设想一个浏览器内的采样数据处理工具：主线程收集一批浮点数，Worker对它们做数值处理，再把结果交还界面。如果由我排查这类场景，我会先分开看计算与消息传递成本，而不会只因计算已放进Worker就认定主线程开销已经消失。这是说明机制的假设场景，没有性能实测数字。

普通postMessage使用结构化克隆传递数据。对于可转移的ArrayBuffer，显式指定转移可避免复制其底层内存数据，但消息元数据的处理、任务调度和Worker启动仍有开销。小数组或很短的计算未必因此获得整体加速。

检查对象：转移 ArrayBuffer 而不是数组视图

数组视图本身不放入转移列表，应放values.buffer。消息对象中则必须让接收端能够拿到这个数据，例如携带values视图或buffer字段。转移列表只声明哪些资源要转移，不会自动把该资源添加为消息字段。

如果一个ArrayBuffer上有多个视图，转移影响的是整个缓冲区，它们在原端都不能再访问原数据。这不是仅仅清空某一个变量，也不是通过保留别名就能继续使用。

修复消息：同时提供数据和转移列表

下面用两个文件演示一次往返。将main.js作为页面脚本加载，把processor.js放在同目录，使用HTTP或HTTPS提供页面；Worker脚本路径相对当前文档解析，并需符合站点同源与CSP规则。示例代码未在本机启动浏览器执行。

main.js：

const worker = new Worker("./processor.js");
const values = new Float32Array([2, 4, 6, 8]);

worker.onmessage = ({ data }) => {
  // 返回消息中的视图拥有接收端可用的缓冲区。
  const result = data.values;
  console.log("结果", Array.from(result));
  worker.terminate(); // 一次性任务结束，释放Worker。
};
worker.onerror = (event) => {
  console.error("处理失败", event.message);
  worker.terminate();
};
worker.onmessageerror = () => {
  console.error("返回消息无法反序列化");
  worker.terminate();
};
try {
  // 视图在消息里，底层缓冲区在转移列表里。
  worker.postMessage({ values }, [values.buffer]);
  console.log("原buffer字节数", values.buffer.byteLength);
} catch (error) {
  // 捕获发送时的数据克隆等同步错误。
  worker.terminate();
  throw error;
}

processor.js：

self.onmessage = ({ data }) => {
  const values = data.values;
  // 在Worker当前拥有的视图上原地处理，不另建结果数组。
  for (let index = 0; index 

这段代码只承担一次任务，适合说明所有权变化。持续处理多批数据时，应复用Worker、为消息添加任务标识并限制在途任务数量，不能无限发送数据包。示例中的Array.from用于展示少量结果，本身会创建普通数组；生产环境处理大数据时不应只为日志再复制全部结果。

结果判断：原缓冲区分离，返回值重新接收

对本例非空缓冲区而言，发送成功后原values.buffer.byteLength应为0；收到结果后，新消息里的values可读取，按示例计算应得到[1, 2, 3, 4]。这些是机制推导和读者判断标准，不是已执行日志。分离不代表Worker业务处理已经成功，发送返回也不代表对端计算已经完成。

即使Worker把数据转移回来，最初主线程里的values对象也不会重新恢复。应使用返回消息中新建的视图引用。调试时区分“同一批数值又回到主线程”和“原来的JavaScript对象恢复可用”，后者并不成立。

如果要比较耗时，应固定数据大小和处理逻辑，分别观察消息往返与整体任务耗时，并考虑Worker预热、日志和垃圾回收等因素。转移机制减少的是缓冲区复制，不承诺固定倍数加速，也不保证整个程序没有任何内存分配。

排错清单：共享视图、切片和任务失败

遇到DataCloneError，先看转移列表是否放了TypedArray而非buffer、是否重复放入同一个缓冲区、是否尝试再次转移已经分离的缓冲区，以及消息中是否混入不可克隆值。消息发送的同步异常与Worker内部运行错误是不同出口，示例分别使用try/catch和error事件处理。

subarray创建的是共享同一底层buffer的视图。把一个很大数组的微小subarray发出并转移其buffer，涉及的是整个底层缓冲区，原端其他视图也受影响。如果只想交出选定区间，可以先用TypedArray.slice生成独立副本再转移它，但这一次主动复制应计入成本，不能声称完全零复制。

发送后Worker若异常退出，原端数据不会自动回滚恢复。业务需要重试时，要能够从文件、原始输入或另外保留的数据重建任务；若主线程仍必须同时读取原数据，通常应选择克隆或在设计时保留独立副本，而不是转移后继续访问旧视图。

只写转移列表、不写消息里的数据可以吗？

接收端无法仅从转移列表获取数据字段。应将buffer或关联视图放进消息，使接收方可访问。

Worker返程也需要转移列表吗？

若希望返程也避免复制可转移缓冲区，需要在返程postMessage中同样显式指定。

transferable是不是共享数组？

不是，ArrayBuffer转移交出资源所有权。共享内存是另一套并发模型，本例不采用。

维护方参考：Transferable对象与缓冲区转移、Worker.postMessage参数说明。