要让postMessage真正实现ArrayBuffer零拷贝，关键是通过transfer列表显式移交内存所有权；仅传ArrayBuffer而不填transfer列表会触发结构化克隆，导致深拷贝、内存翻倍和主线程卡顿。
要让 postMessage 真正实现 ArrayBuffer 的零拷贝，关键不是“传数据”，而是“交出内存控制权”。只要没显式移交所有权，哪怕传的是 ArrayBuffer，也会触发结构化克隆——大数组卡顿、内存翻倍、主线程卡死，全因此而起。
哪些 ArrayBuffer 能零拷贝传递
只有原生的 ArrayBuffer 实例本身支持转移，它的视图（如 Uint8Array、Float32Array）不能直接进 transfer 列表。常见可转移对象包括：
-
ArrayBuffer：最常用，图像帧、音频缓冲、数值矩阵都靠它 -
ImageBitmap：解码完成的位图，转移后主线程立刻无法读像素 -
OffscreenCanvas：Chrome/Edge 支持好，Safari/Firefox 部分支持 -
MessagePort：用于 Worker 间双向通信 -
AudioData和VideoFrame：WebCodecs 相关，需检查浏览器支持
字符串、普通对象、JSON、Date、TypedArray 视图等都不行。把 Uint8Array 直接塞进 transfer 列表会抛 DataCloneError。
怎么写才能真正零拷贝
必须用 postMessage(data, transferList) 形式，且 transferList 中只放可转移对象本身（比如 buffer，不是 view），并且只能转移一次。
- ✅ 正确：
worker.postMessage(buffer, [buffer]) - ✅ 正确：
worker.postMessage(view, [view.buffer])（取视图的.buffer） - ✅ 正确：
worker.postMessage({data: buffer}, [buffer])（包裹不影响转移） - ❌ 错误：
worker.postMessage(buffer)（无 transfer 列表 → 深拷贝） - ❌ 错误：
worker.postMessage(view, [view])（视图不可转移）
转移完成后，原 ArrayBuffer 立即被 detach，buffer.byteLength 变为 0，任何后续访问都会静默失败或抛错。
Worker 端怎么安全使用
接收方拿到的是同一段物理内存的引用，不是副本。需按需重建 TypedArray 视图，无需复制数据：
- 如果主线程发的是
buffer，Worker 中直接new Uint8Array(e.data) - 如果主线程发的是
{arr: view}，Worker 中需解构：const {arr} = e.data; new Uint8Array(arr.buffer) - 别写
e.data.buffer——若e.data就是 buffer，它没有.buffer属性
视图类型（Uint8Array、Float32Array）和长度应与主线程一致，否则可能读错内存布局。
跨域和兼容性要注意什么
跨 iframe 或跨窗口通信时，transferList 在旧版 Chromium（v88 之前）会被静默忽略，表面无报错，实则退化为深拷贝。验证是否成功转移，可在接收端检查 e.data.byteLength === 0（主线程）或 e.data.byteLength > 0（Worker）。推荐底线支持：
- Chrome 89+、Firefox 72+、Safari 15.4+
- Edge 基于新版 Chromium，基本一致
- SharedArrayBuffer 跨域默认禁用，需配合 COOP/COEP 头，不能替代 transfer
别信“二进制克隆算法”——标准中不存在这个东西。structuredClone 仍是拷贝，且不支持 transfer；混用反而多一次复制，更慢。
