structuredClone 配合 transfer 选项可实现元数据深拷贝与二进制数据零拷贝移交，避免内存翻倍：元数据用 structuredClone 处理，ArrayBuffer 等可转移对象通过 transfer 列表移交所有权。

直接用 structuredClone() 处理大数据，内存会瞬间翻倍——因为默认就是深拷贝。想压低内存峰值、又不牺牲数据完整性，关键不是“不用 structuredClone”，而是让它只管该管的，把大块二进制数据交给 Transferable 机制来移交所有权。

明确分工：哪些该克隆，哪些该转移

structuredClone 支持 transfer 选项，它不是替代 transfer，而是融合——让 structuredClone 负责结构化元数据（如配置、时间戳、ID），把 ArrayBuffer、ImageBitmap 等可转移对象从原对象中“拎出来”，单独移交。

• 元数据（轻量、需保留引用关系）→ 用 structuredClone 深拷贝
• 载荷（ArrayBuffer、TypedArray.buffer、OffscreenCanvas）→ 加入 transfer 列表，零拷贝移交
• TypedArray 本身不可转移，但它的 .buffer 可以。别传 uint8Array，要传 uint8Array.buffer

正确写法：带 transfer 的 structuredClone 调用

错误写法是先 clone 再手动 transfer，或把整个大对象丢给 postMessage；正确路径是让 structuredClone 在克隆过程中就接管转移逻辑：

人工智能数字技术机器人全息大脑大数据分析矢量素材(EPS)

这是一款人工智能数字技术机器人全息大脑大数据分析矢量素材，格式为 EPS，含 JPG 预览图。

下载

• structuredClone({ id: 1, config: { mode: 'fast' } }, { transfer: [arrayBuffer] })
• 返回对象中 arrayBuffer 字段仍存在，但其底层内存已归属新上下文
• 主线程原 arrayBuffer 立即变为 detached：访问 arrayBuffer.byteLength 返回 0，读写静默失败

避免常见误操作

转移不是万能加速键，用错反而拖慢：

• 别对几 KB 的小 buffer 用 transfer——调度开销可能超过拷贝成本
• 别在 transfer 列表里重复写同一个 buffer，浏览器会报错
• 别指望 transfer 后还能在主线程继续用视图（如 Uint8Array）——必须确保所有基于它的视图都已释放
• 如果对象含多个 buffer，每个都要显式列进 transfer 数组，不能只写一个

典型场景示例：图像处理任务

假设你传一个含元信息和像素数据的对象：

• 原始对象：{ taskId: 'img-123', format: 'webp', timestamp: Date.now(), pixels: new Uint8ClampedArray(...) }
• 优化后传输：worker.postMessage(structuredClone(obj, { transfer: [obj.pixels.buffer] }), [obj.pixels.buffer])
• Worker 收到的是完整元数据副本 + 一个拥有像素内存所有权的 pixels 视图
• 主线程立即失去像素访问权，内存不翻倍，序列化只跑元数据部分