深拷贝高效的关键是避免复制而用所有权转移实现零拷贝：imagebitmap通过transfertoimagebitmap和postmessage([bitmap])移交控制权；arraybuffer需用transfer列表postmessage({pixels:buffer},[buffer])实现真零拷贝；禁用getimagedata、structuredclone等假深拷贝操作。
深拷贝在 Canvas 图像像素数据（ImageData）或 ArrayBuffer 处理中，**高效的关键不是“复制”，而是避免复制——用所有权转移实现零拷贝**。真正高性能的方案，是绕开传统深拷贝逻辑，直接移交内存控制权。
ImageBitmap + transferToImageBitmap 实现图像零拷贝转移
主线程中生成图像位图后，不调用 getImageData()（会触发像素读取和内存分配），而是直接用 transferToImageBitmap() 提取解码后的 GPU/内存就绪位图：
-
一步到位：Canvas 渲染完成后调用
canvas.transferToImageBitmap()，返回一个可转移的ImageBitmap对象 -
零拷贝发送：通过
worker.postMessage(bitmap, [bitmap])将其所有权移交 Worker，主线程原引用立即失效（bitmap.close()不再需要） -
Worker 端直用：接收后可用
createImageBitmap()或OffscreenCanvas.transferFromImageBitmap()直接绘制或处理，无需解码、无需Uint8ClampedArray拷贝
⚠️ 注意：Firefox 和 Safari 对 ImageBitmap 转移支持较晚，上线前务必实测兼容性。
ArrayBuffer 用 transfer 列表实现真零拷贝传递
若已持有原始像素缓冲（如从摄像头、WebRTC 或 WASM 获取的 ArrayBuffer），应跳过任何 Uint8Array 视图拷贝，直接转移底层缓冲：
-
只传 buffer，不传视图：不能写
postMessage(new Uint8Array(buffer), [buffer])，而要提取view.buffer后转移 -
正确写法：
worker.postMessage({ pixels: buffer }, [buffer])—— 第二个参数[buffer]是转移列表，表示移交所有权 -
转移后状态：主线程中
buffer.byteLength变为 0；Worker 收到的是同一块物理内存，可立即构造new Uint8ClampedArray(buffer)操作像素
✅ 适合 ≥1MB 的单次大块图像数据；❌ 不适用于高频小帧（此时 SharedArrayBuffer + Atomics 更合适）。
避免踩坑：哪些操作等于“假深拷贝”
以下看似在做“深拷贝”，实则引入额外内存分配与拷贝，破坏性能：
-
ctx.getImageData()→ 返回新分配的ImageData，含全新Uint8ClampedArray，必拷贝像素 -
structuredClone(arrayBuffer)无transfer参数 → 底层仍执行内存复制，非零拷贝 -
new Uint8Array(oldBuffer)→ 创建新视图，但若oldBuffer未转移，只是共享同一内存，不算拷贝；若配合.slice()或new Uint8Array(oldBuffer).buffer，反而触发新分配 -
JSON.stringify() + JSON.parse()→ 仅支持可序列化字段，丢失像素精度、类型信息，且极慢
补充：真需要深拷贝时的务实选择
极少数场景（如需保留主线程像素副本、调试、多路并行处理）必须深拷贝，推荐：
- 小数据（：用
structuredClone(buffer, { transfer: [buffer] })—— 注意：这其实是转移，不是拷贝；若真要副本，去掉transfer，但代价是内存翻倍 -
大数据 + 兼容旧环境：手动
new Uint8Array(new ArrayBuffer(src.length)).set(src)，比slice()更明确，且避免ArrayBuffer.slice()的隐式分配 -
跨平台图像处理（如鸿蒙 PixelMap）：走
readPixelsToBuffer → createPixelMap流程，本质是显式申请新缓冲并填充，属于可控深拷贝
不复杂但容易忽略：零拷贝不是魔法，它依赖明确的所有权移交协议。只要记住——transfer 列表里没它，就是深拷贝；transfer 列表里有它，才是真零拷贝。
