核心办法是绕过结构化克隆，改用 transferable 对象实现零拷贝传输：通过 transferlist 移交 arraybuffer 所有权，使主线程 buffer 变 null、worker 获得同一内存，避免深拷贝卡顿；适用于 uint8array、blob.arraybuffer() 等，禁用 imagedata、file 直传；需节流输出、分离元数据与二进制数据，并用 performance 和 memory 面板验证移交生效。
核心办法是绕过结构化克隆，改用 transferable 对象 实现零拷贝传输。结构化克隆对大文件（如 arraybuffer、typedarray、blob）会同步深拷贝，主线程卡顿明显，10mb 数据拷贝就可能耗时 15–25ms；而 transferable 只传递内存所有权，耗时压到 0.1–0.5ms。
用 transferList 移交 ArrayBuffer 所有权
这是最直接有效的优化。主线程创建 ArrayBuffer 后，不直接传对象，而是把 .buffer 加入 transferList：
- 正确写法：
worker.postMessage({type: 'load', data}, [data.buffer])—— 此后主线程的data.buffer变为null，Worker 拿到的是同一块内存 - 错误写法：
worker.postMessage({data})—— 触发结构化克隆，内存双份 + 主线程阻塞 - 适用于
Uint8Array、Float32Array、Blob.arrayBuffer()等返回 ArrayBuffer 的场景
避免传 ImageData、File 等不可移交对象
ImageData 本身不可 transferable，但它的 .data 是 Uint8ClampedArray，可取 .data.buffer 移交；File 对象不能移交，需先调用 file.arrayBuffer() 转成 ArrayBuffer 再移交：
- 图像处理场景：主线程读取图片 →
ctx.getImageData()→ 提取imageData.data.buffer→postMessage(..., [buffer]) - 文件上传场景：监听
input[type=file]→file.arrayBuffer()→ 移交 buffer，Worker 内直接用new Uint8Array(buffer)处理 - 不移交时，DevTools Memory Snapshot 中能看到主线程和 Worker 各持一份副本，内存翻倍
拆分消息 + 控制输出节奏
即使用了 transfer，若 Worker 频繁发回大量结果，主线程 onmessage 回调堆积仍会造成 UI 抖动：
- Worker 内部做节流：每处理 100 帧图像、或每 50ms 才
self.postMessage()一次，避免“突发式”输出 - 主线程 onmessage 中只存结果、触发
requestAnimationFrame或setTimeout(0)延后更新 UI，不直接操作 DOM - 必要时把元数据（id、时间戳）和二进制数据分开发送，减少单次消息体积
监控与验证是否生效
光改代码不够，得确认优化真正落地：
- 用
performance.mark()包裹postMessage()前后，测主线程阻塞时间是否从百毫秒降到亚毫秒级 - Chrome DevTools → Performance 面板 → 录制 → 过滤 “postMessage”，看
serializeDataForTransferring是否消失或耗时趋近于 0 - Memory 面板拍快照：移交成功后，主线程中对应 ArrayBuffer 应显示为
(detached)，Worker 堆中才持有完整 buffer
