ArrayBuffer深拷贝关键是决定是否复制内存，高性能场景应避免复制、直接转移所有权；优先用transfer实现零拷贝，需通过postMessage第二个参数移交控制权；必须保留原buffer时才用structuredClone；须避开new Uint8Array(buffer)等假深拷贝陷阱；ImageData场景应使用transferToImageBitmap零拷贝。
处理 ArrayBuffer 的深拷贝，关键不是“复制内容”，而是决定要不要真正复制内存——大多数高性能场景下，应该避免复制，直接转移所有权。
优先用 transfer 实现零拷贝
当你要把 ArrayBuffer 传给 Web Worker 或跨上下文使用时，transfer 列表是最高效的方式：
- 写法是
worker.postMessage({ data: buffer }, [buffer])，第二个参数[buffer]表示移交控制权 - 移交后，主线程的
buffer.byteLength立即变为 0，Worker 收到的是同一块物理内存 - Worker 中可直接用
new Uint8ClampedArray(buffer)或其他视图读写，无额外开销 - 适用于单次大块数据（如 ≥1MB 的图像帧、音频缓冲），不适用于高频小帧
需要真复制时才用 structuredClone
如果必须保有原 buffer 并生成一份独立副本（比如做校验、备份或并行处理），用 structuredClone：
- 基础用法：
const copy = structuredClone(buffer)，会分配新内存并逐字节复制 - 注意：这仍是深拷贝，但性能代价高；100MB 的 buffer 复制会瞬间多占 100MB 内存
- 不要和 transfer 混用——
structuredClone(buffer, { transfer: [buffer] })实际上等价于直接 postMessage + transfer，不是复制
明确避开“假深拷贝”陷阱
以下操作看似在深拷贝，实则低效甚至错误：
立即学习“Java免费学习笔记（深入）”；
-
new Uint8Array(buffer)后再传入postMessage：只传视图没传 transfer 列表，底层仍复制整块内存 -
JSON.parse(JSON.stringify(buffer))：不支持 ArrayBuffer，会变成空对象或报错 - 手写递归遍历
buffer字节：既不可靠又极慢，完全没必要
结合 ImageData 场景的特别提醒
如果你是从 Canvas 获取像素数据，根本不要调用 getImageData()：
- 它返回新分配的 ImageData，内部必拷贝像素，属于典型假深拷贝
- 正确路径是：
canvas.transferToImageBitmap()→postMessage(bitmap, [bitmap]) - Worker 收到 ImageBitmap 后，可用
createImageBitmap()或离屏 canvas 直接绘制，全程零拷贝
