主线程与worker通信性能优化核心是避免拷贝：用transferable objects（如arraybuffer）实现零拷贝；用messagechannel建立双向低开销通道；精简载荷，只传必要原始数据；https下可用sharedarraybuffer+atomics共享内存。
主线程和 Worker 之间通信默认走结构化克隆（Structured Clone），大数据量时会明显拖慢性能——序列化、内存复制、反序列化三步全要花时间，还可能触发频繁 GC。解决的核心思路是：能不拷贝就不拷贝，能少序列化就少序列化。
用 Transferable Objects 实现零拷贝传输
这是最常用、最有效的优化手段。把 ArrayBuffer、MessagePort 等可转移对象通过 postMessage(data, [transferList]) 的第二个参数移交所有权，浏览器直接把内存地址“转交”过去，原线程立即失去访问权，不复制、不序列化。
- 支持类型包括：
ArrayBuffer、MessagePort、ImageBitmap、OffscreenCanvas、SharedArrayBuffer - 移交后主线程再读
buffer.byteLength会是 0，说明已失效，不能再用 - 适合传输大数组、图像像素、几何体顶点数据等二进制密集型内容
用 MessageChannel 建立专用通信通道
相比 worker.postMessage() 的单向广播式通信，MessageChannel 提供一对 MessagePort，可以建立点对点、双向、低开销的连接。
- 主线程创建
const channel = new MessageChannel()，把channel.port2发给 Worker - Worker 收到后调用
port.start()，之后双方用各自的 port 直接postMessage - 优势在于避免全局消息队列竞争，也天然支持 Transferable 对象传递
避免传非必要对象，精简通信载荷
结构化克隆无法处理函数、DOM 节点、Error、RegExp 等，且对嵌套深、引用多的对象效率更低。实际开发中应主动规避：
- 不要传整个 Three.js 对象（如
BufferGeometry），改用geometry.attributes.position.array提取原始Float32Array再转移 - 避免传大型纯 JS 对象（如含百个字段的配置对象），只传真正需要计算的字段或 ID
- 用
Uint8Array、Float64Array替代普通数组，更利于转移和 Worker 端高效处理
共享内存场景下用 SharedArrayBuffer + Atomics
在 HTTPS 或 localhost 环境中，可用 SharedArrayBuffer 让主线程与多个 Worker 共享同一块内存，彻底绕过消息传递。
- 主线程创建
new SharedArrayBuffer(size)，再构造视图（如Int32Array(sharedBuf)） - 把
sharedBuf作为 Transferable 对象发给 Worker，Worker 用相同方式构造视图 - 读写需配合
Atomics.wait()/Atomics.notify()做同步，防止竞态 - 适用于高频、小粒度、多轮交互的计算任务（如实时音频处理、粒子模拟）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
