Web Worker Transferable Objects大数组传给 Worker 为什么仍然卡顿怎样完成一个可复用的最小示例

把大数组交给 Web Worker 后仍然卡顿，通常不是 Transferable 失效，而是把“跨线程复制”误认为“所有成本都消失”。Transferable 只转移 ArrayBuffer 的资源所有权：主线程不再拥有这块缓冲区，Worker 接管它；主线程创建、填充数组的时间、发送过多小消息的调度成本，以及 Worker 内部计算仍然存在。

这篇只讨论 Dedicated Worker 与大数组的单向传输。核心规则可以先记住：Uint8Array、Float32Array 是视图，真正放入 transfer 列表的应是它们的 buffer；转移之后，发送端不要再读写原视图。

先检查：传的是视图，还是它的 ArrayBuffer

普通 worker.postMessage(data) 会通过 structured clone 处理消息。对于大块连续内存，正确的 Transferable 写法是把缓冲区放进消息，同时把同一个缓冲区放进第二个参数的 transfer 列表。列表只声明哪些资源要转移，并不会替你把资源放进消息。

因此下面两种对象要分开理解：new Uint8Array(buffer) 只是一个访问窗口，buffer 才是拥有内存资源、可以转移的对象。若只把视图放入消息而没有 transfer，数据仍可能被复制；若只把 buffer 放入列表却没把它作为消息数据的一部分，发送端会失去资源而接收端拿不到它。

最小可复用示例：一次性转移大数组

把主线程和 Worker 拆成两个文件，示例只保留“构造缓冲区—转移—Worker 创建视图”的最小闭环。这里的填充循环是示意：真实项目应把耗时构造也纳入排查，而不是把卡顿全部归因于 postMessage。

// main.js：主线程只负责准备一次数据并转移所有权
const worker = new Worker("worker.js");
const buffer = new ArrayBuffer(32 * 1024 * 1024);
const input = new Float32Array(buffer);

// 这一步会占用主线程；大数组初始化本身也可能造成卡顿
input.fill(1);

worker.postMessage({ buffer }, [buffer]);

// 转移后主线程不再拥有这块内存，不能继续读取 input 或 buffer
console.log("发送端 byteLength:", buffer.byteLength); // 0

// worker.js：Worker 接管 buffer 后再创建自己的视图
self.onmessage = ({ data }) => {
  const values = new Float32Array(data.buffer);
  let sum = 0;

  // 计算发生在 Worker；这里的循环不会把结果写回主线程内存
  for (let i = 0; i 

这段示例的关键不是输出数值，而是所有权边界：buffer.byteLength 在发送端变为 0，Worker 端通过 data.buffer 重新建立视图。若业务还需要主线程继续使用原数据，就不能把同一缓冲区转移后继续复用，应改为复制一份、重新生成一块缓冲区，或把数据拆成可独立管理的批次。

已经 Transferable 仍卡顿：按三层检查

第一层看构造。主线程若先分配并填满数十 MB 的 TypedArray，页面仍会在这一段阻塞；可以延后填充、缩小单批大小，或让 Worker 自己生成可生成的数据。Transferable 不会把主线程的分配和写入变成异步。

第二层看消息。循环中每个小片段都调用一次 postMessage，即使每次都转移，也会积累事件排队和调度成本。优先把相邻片段合并成较少的批次，并让每个批次拥有独立的 ArrayBuffer；不要为了复用已转移的 buffer 而访问 detached 视图。

第三层看计算。转移只改变内存所有权，不能降低 Worker 内部的遍历、解析或转换复杂度。主线程只接收计数、状态或摘要等小结果，Worker 需要回传原始数据时，再明确决定是转移结果 buffer 还是只回传必要字段。

最后清单：什么时候该用 Transferable

• 数据是大块二进制或 TypedArray 底层的 ArrayBuffer，并且发送端可以放弃这块内存时，适合转移。
• 发送端还要继续读写同一对象时，不要强行转移；所有权变化比一次复制更容易造成逻辑错误。
• 页面仍卡顿时，依次观察主线程构造、消息次数和 Worker 计算，不要只检查 transfer 列表。

简而言之，Transferable 解决的是“大对象跨上下文复制”这一项成本，不是完整的性能优化方案。把资源转移成功、让发送端停止使用原视图，再用批量消息和合理的计算分工，才是可复用的最小实现边界。

常见问题

为什么不能把 Uint8Array 直接放入 transfer 列表？

TypedArray 是视图而不是拥有底层内存的可转移资源。应把它的 buffer 放入消息和 transfer 列表；Worker 收到后再按需要创建视图。

转移后还能读取主线程的原数组吗？

不能把它当作仍可用的数组继续读写。底层 buffer 已经 detached，若业务需要两边同时使用，应采用复制或准备独立缓冲区。