HTML5零拷贝高性能传递需使用Transferable Objects机制，仅ArrayBuffer、ImageBitmap、MessagePort、OffscreenCanvas、AudioData等特定类型支持，且必须通过postMessage(data, [transferList])显式声明移交所有权。
要在HTML5中实现超大数据的零拷贝高性能传递，核心是用好Transferable Objects机制——它不复制内存，而是直接移交对象所有权。关键不在“传数据”，而在“交控制权”。
哪些数据能走零拷贝通道
只有特定类型支持转移，普通对象、字符串、JSON、Date等都不行，强行传会退化为结构化克隆，反而更慢。真正能零拷贝的包括：
- ArrayBuffer：最常用，适合图像帧、音频缓冲、数值矩阵等二进制载荷
- ImageBitmap：解码后的图像位图，转移后主线程立刻无法读取像素
- MessagePort：用于建立Worker间双向通信管道
- OffscreenCanvas（Chrome/Edge支持较好，Safari/Firefox部分支持）
- AudioData（Web Audio API实验性功能，需检查浏览器支持）
怎么写才真正零拷贝
光有可转移对象还不够，必须显式声明转移意图。postMessage第二个参数就是“移交清单”，漏掉它就等于没用Transferable。
- 错误写法：
worker.postMessage(buffer)→ 触发结构化克隆，大buffer卡主线程 - 正确写法：
worker.postMessage(buffer, [buffer])→ 内存地址直接移交，原buffer.byteLength变为0 - 若传的是TypedArray（如Uint8Array），得先取
view.buffer再放进transfer列表，不能直接传view - 一个ArrayBuffer只能转移一次；转移后再传，会抛
DataCloneError
配合Web Worker的典型流水线
零拷贝的价值在端到端流程里才能释放，尤其处理百万级数据时：
立即学习“前端免费学习笔记（深入）”；
- 主线程fetch得到
response.arrayBuffer()，不解析、不转视图，直接postMessage(buffer, [buffer]) - Worker收到后，用
new Uint8Array(buffer)或new Float32Array(buffer)按需解析，边处理边丢弃局部引用 - 处理结果不攒大包，拆成小批次（如每1000条一组）用普通postMessage回传，避免Worker内存堆积
- 主线程渲染时只处理当前批次，保持60fps流畅
别踩这些性能陷阱
零拷贝不是万能银弹，用错场景反而拖慢整体：
- 高频小数据（比如每毫秒传几个数字）：频繁转移开销可能超过复制成本，此时考虑
SharedArrayBuffer + Atomics更合适 - 需要主线程持续读写同一份数据：转移后原引用失效，不可逆，这种情况该用
structuredClone()保副本 - 跨浏览器兼容：ImageBitmap转移在Firefox和Safari中支持较晚，上线前务必实测
- 误传不可转移类型：比如把
{ config: true }和大buffer一起塞进transfer数组，整个postMessage会失败
