arraybuffer通过transferable机制可零拷贝移交，显著提升多线程性能；结构化克隆为深拷贝、耗时随数据量增长；sharedarraybuffer支持多线程共享内存但需atomics同步，适用于高频小粒度交互。
ArrayBuffer 本身不能直接跨线程传递，但通过 transferable objects 机制（即 postMessage 的第二个参数传入 [arrayBuffer]）可实现零拷贝移交，这是提升多线程数据传递性能的关键。
Transferable 传递：真正高效的核心
普通 postMessage(arrayBuffer) 会触发结构化克隆（深拷贝），大数据量时耗时显著；而使用 transfer 方式：
- 主线程调用
worker.postMessage(buffer, [buffer])后，原 buffer 立即变为detached，不可再访问 - Worker 线程收到的是同一段内存的引用，无复制开销，延迟接近常数级
- 适用于
ArrayBuffer、SharedArrayBuffer（需配合 Atomics）、MessagePort、ImageBitmap等
SharedArrayBuffer：共享内存 + 同步控制
与 transfer 不同，SharedArrayBuffer 允许多个线程**同时读写同一块内存**，但需手动同步：
- 必须在支持
crossOriginIsolated的上下文中启用（需COOP/COEP响应头） - 写操作需搭配
Atomics.wait()/Atomics.notify()或Atomics.store()避免竞态 - 适合高频、小粒度交互（如实时音频处理、游戏状态同步），但编程复杂度明显高于 transfer
性能对比关键指标（以 10MB ArrayBuffer 为例）
实测典型环境（Chrome 120+，中高端桌面 CPU）下：
- Transferable 传递：≈ 0.02–0.05 ms（纯指针移交，与大小几乎无关）
- 结构化克隆（默认 postMessage）：≈ 8–15 ms（随数据量线性增长，100MB 可达百毫秒级）
-
SharedArrayBuffer 访问延迟：单次
Atomics.load()≈ 20–50 ns，但同步逻辑会引入额外开销
实际使用建议
根据场景选择合适方式：
- 一次性大块数据下发（如图像解码结果、模型权重）→ 优先用
transfer - 双向低延迟协同（如 WebAssembly 模块与 JS 实时通信）→ 考虑
SharedArrayBuffer+Atomics - 避免混合使用：不要对已 transfer 的 buffer 再尝试 shared 或 clone，会抛出
Detached ArrayBuffer异常 - 调试时可用
ArrayBuffer.isView()和buffer.byteLength快速判断状态，buffer.detached（非标准，但 Chrome/Firefox 支持）可辅助检测
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
