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 在克隆过程中就接管转移逻辑：
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视图 - 主线程立即失去像素访问权，内存不翻倍，序列化只跑元数据部分
