在当今的 Web 开发中，主线程与 Web Worker 之间传递复杂对象早已不是技术难题。借助浏览器内置的结构化克隆算法，开发者可以轻松实现安全的数据交换。
核心技巧非常直接：只需调用 postMessage() 即可。浏览器底层会自动触发结构化的克隆机制，整个过程既安全又无感知。发送方与接收方得到的对象是彼此独立的深度拷贝，从根本上避免了线程间的数据污染。只要你的对象属于可克隆范围，传输过程几乎可以做到“零配置”。
哪些对象能安全传递
那么，什么样的对象能够被安全地传递呢？结构化克隆算法支持的清单相当丰富，关键在于克隆后的对象会完整保留原有的类型与行为。例如，在 Worker 中接收到的 Date 对象依然可以正常调用 .getTime() 方法。
- 基础值：包括
null、布尔值、各类数字、字符串，以及在现代环境中支持的BigInt。 - 容器类：普通的
Object和Array自然不在话下，像Map、Set这样的集合也能完整克隆，传递后依然保持为Map和Set实例，而不会被降级为空对象。 - 时间与正则：
Date对象会保留精确的时间属性，RegExp也会完整保存匹配模式及其test方法。 - 二进制与文件：处理音视频或图像数据时常用的
ArrayBuffer、TypedArray、Blob、File、ImageData均在支持之列。 - 特殊结构：即使对象内部存在复杂的循环引用，算法也能自动识别并正确重建，绝不会引发栈溢出错误。
当然，也存在硬性限制。不支持的类型包括函数、Promise 对象、DOM 元素、WeakMap，以及以 Symbol 作为键的属性（这些键会被静默忽略）。如果尝试传递这些类型，浏览器将直接抛出 DataCloneError 异常。此外，undefined 作为属性值时的处理，在部分旧版浏览器中可能存在不一致性。
为什么不必手动执行 structuredClone 再调用 postMessage
这里有一个常见的误解：既然 postMessage 底层已经使用了克隆，那么先手动调用 structuredClone() 再传递，是否更安全？实际上，这种做法在现代浏览器中完全是多余的。主流浏览器（Chrome 98+、Firefox 94+、Safari 15.4+）在调用 postMessage(data) 时，内部已经强制采用结构化克隆算法来序列化数据。因此，像 worker.postMessage(structuredClone(obj)) 这样的写法不仅不会带来额外的安全性或性能提升，反而会在主线程中增加一次同步的深度拷贝开销，纯属画蛇添足。
正确的做法十分简洁：
- 在主线程，直接使用
worker.postMessage(state)。 - 在 Web Worker 内部，通过
event.data获取到的就已经是主线程原始对象的完全独立副本。 - 因此，在 Worker 中完全没有必要再次调用
structuredClone(event.data)。
大对象传输优化：利用 Transfer 实现零拷贝
不过，当需要传递像 ArrayBuffer 或 TypedArray 这样的大型二进制数据（例如视频帧、音频缓冲区）时，默认的克隆机制会完整复制整块内存，这可能成为性能瓶颈。此时，就该启用 postMessage 的“Transfer”机制了。它的核心思想是“移交”而非“复制”，从而实现真正的零拷贝：
- 在主线程发送时，将对象数组作为第一个参数，并将要移交的
ArrayBuffer放在第二个“Transfer”列表里：worker.postMessage({ data, buffer }, [buffer])。 - 一旦发出，主线程中原始的
buffer会立即被“清空”（表现为buffer.byteLength === 0），所有权转移给了 Worker 线程。 - Worker 线程接收到的则是指向同一块物理内存的引用，没有产生任何额外的内存占用。
- 需要注意的是，能够被 Transfer 的类型比较有限，主要是
ArrayBuffer、MessagePort、ImageBitmap等几种。
兼容性与降级策略
最后来谈一下兼容性问题。如果你的应用仍需支持旧版浏览器，或者运行环境不确定，可以采取一些降级方案。首先，可以通过 typeof structuredClone === ‘function’ 来检测当前环境是否原生支持该 API。一个常见的“安全封装”示例如下：
const safeClone = (obj) => {
try { return structuredClone(obj); }
catch { return JSON.parse(JSON.stringify(obj)); }
};这里必须郑重提醒：降级使用的 JSON.parse(JSON.stringify(obj)) 方案仅适用于纯数据对象（即只包含数字、字符串、数组和纯对象）。它会无情地丢失 Date、Map、RegExp 等特殊类型的语义，将它们转换为字符串或空对象。因此，绝不能在需要保持类型精确性的场景下依赖此降级方案。
