ArrayBuffer.prototype.transfer()是ES2025引入的零拷贝内存转移特性，通过移交所有权而非复制数据实现高效传输，调用后原buffer变为detached状态，目标环境直接获得同一物理内存控制权。
ArrayBuffer.prototype.transfer() 是 ES2025 引入的关键性能特性，它让 ArrayBuffer 的跨环境（如主线程 ↔ Worker、Worker ↔ Worker）传输真正实现“零拷贝”——不是跳过复制动作，而是跳过复制这个行为本身。核心在于：不搬数据，只移交内存所有权。
transfer() 不是复制，是“交钥匙”
调用 buffer.transfer() 后，原 ArrayBuffer 立即变为 detached（分离状态），byteLength 变为 0，所有基于它的 TypedArray 视图（如 Uint8Array）读写静默失败。而目标环境拿到的是同一块物理内存的控制权，无需 CPU 逐字节搬运，也不新增内存占用。
- 100 MB 的 ArrayBuffer 转移耗时约 4 ms，内存峰值增长为 0
- 同等大小若用
structuredClone或普通postMessage，会触发完整内存拷贝，峰值 +100 MB，耗时达 280 ms+ - transfer() 是同步操作，不依赖事件循环，无调度延迟
它和 postMessage/structuredClone 中的 transfer 选项什么关系？
两者底层共享同一套所有权转移机制，但使用场景不同：
-
postMessage(buffer, [buffer])：适用于 Worker 通信，浏览器自动调用 transfer 逻辑 -
structuredClone(obj, { transfer: [buffer] })：适用于混合数据结构，让 structuredClone 处理元数据，同时把 buffer 移交 -
buffer.transfer()：更底层、更直接，适合需精细控制生命周期的场景（如多次移交、配合 resize 或 transfertofixedlength）
注意：transfer() 是 ArrayBuffer 实例方法，不能对 TypedArray 调用；也不能在 transfer 后继续使用原视图——必须确保所有引用已释放。
哪些情况不适合用 transfer()？
零拷贝不是银弹，误用反而拖慢：
- 小于几 KB 的小 buffer：调度开销可能超过拷贝成本
- 需要主线程持续读写原始数据：transfer 后原上下文失效，无法回退
- 未正确释放 TypedArray 视图：即使 buffer 已 transfer，残留视图仍可能引发 detached 异常
- 跨域或非安全上下文：部分浏览器限制 transfer 在非 HTTPS 或非跨域隔离环境中的使用
典型应用组合：元数据 + 载荷分离
真实任务常含轻量结构信息与大块二进制载荷，例如：
{ id: 'task-7', format: 'avif', timestamp: 1746774123, pixels: new Uint8ClampedArray(buffer, 0, size) }
优化做法：
- 用
structuredClone({id, format, timestamp})安全克隆元数据 - 将
pixels.buffer加入 transfer 列表（不是pixels） - 最终发送：
worker.postMessage({ meta, pixels }, [pixels.buffer]) - Worker 收到后，
meta是独立副本，pixels是拥有底层内存的新视图
这样既保元数据一致性，又免载荷拷贝，内存与速度兼顾。
