structuredClone是同步方法，但postMessage自动触发结构化克隆，无需手动调用；仅当需预处理数据、非postMessage场景或兼容旧环境时才需显式使用。
在 Worker 异步通信中，structuredClone 本身是同步方法，但它天然适配异步通信场景——因为 postMessage 机制自动触发结构化克隆，你通常不需要手动调用 structuredClone 来“配合异步”。真正需要关注的，是何时该主动调用、如何避免误用，以及在特殊需求下怎么安全封装异步克隆逻辑。
什么时候必须手动调用 structuredClone？
只有以下情况才需显式使用：
• 你想在发送前修改数据（比如过滤敏感字段、统一时间格式、剔除函数或 DOM 引用）
• 你在非 postMessage 场景操作数据（例如直接赋值给 Worker 实例属性，但这种做法不推荐）
• 需要兼容极旧环境（如 Node.js 早期 Worker 或部分老浏览器），且不能用 polyfill 时，才考虑降级方案（如 MessageChannel 封装）
主线程与 Worker 通信时，克隆其实是自动发生的
只要你用 postMessage 发送对象，浏览器就自动走结构化克隆流程：
• 主线程调用 worker.postMessage(obj) → 系统序列化 obj 成二进制流
• 流经 IPC 通道传输到 Worker 线程
• Worker 收到 event.data 时，已是一个全新、独立、类型完整的副本
• 无需在 Worker 内再写 structuredClone(event.data) —— 它已经是深拷贝结果
需要异步克隆的少数场景：用 MessageChannel 模拟
仅当你要在 Worker 内部对某个大对象做“延迟克隆”或“可控克隆时机”，且环境不支持 structuredClone（极少见），才用 MessageChannel 封装：
• 创建 new MessageChannel()
• 把待克隆对象通过 port1.postMessage() 发出
• 在 port2 上监听 onmessage，收到即为克隆后的新对象
• 这本质是借 IPC 触发一次结构化克隆，但带 Promise 包裹，有微小异步开销
• ⚠ 不推荐日常使用：现代 Worker（Chrome 98+、Firefox 94+、Safari 15.4+）原生支持 structuredClone，直接调用即可
大数据量传输别克隆，优先用 transfer
如果对象含 ArrayBuffer、TypedArray 等可转移类型，别依赖克隆：
• 直接传 buffer 并带上 transfer 列表：worker.postMessage(buffer, [buffer])
• 传输后 buffer.byteLength 变为 0，Worker 收到的是所有权移交后的原始内存块
• 零拷贝、无 GC 压力，适合 >10MB 的图像帧、音频缓冲等场景
• 注意：transfer 后原对象不可再访问，也不能重复 transfer 同一对象
