worker性能瓶颈在于数据传输与内存管理：优先用transferable objects零拷贝传递arraybuffer，高频场景改用sharedarraybuffer+atomics共享访问，大缓冲区需分片流式处理，并及时释放或复用内存。
Worker 线程处理大型内存缓冲区时，性能瓶颈往往不在计算本身，而在于数据传输开销和内存管理方式。关键不是“怎么算”，而是“怎么传、怎么用、怎么交还”。
用 Transferable Objects 避免拷贝
主线程传 ArrayBuffer 给 Worker 时，默认会走结构化克隆（深拷贝），10MB 数据就要复制 10MB —— 耗时且占双份内存。启用可转移对象，是零拷贝的前提。
- 主线程调用
postMessage(data, [buffer])，第二个参数明确列出要转移的 ArrayBuffer - 转移后，主线程中该 buffer 的
byteLength立即变为 0，不能再读写 - Worker 收到的就是原生内存块，可直接构造
Uint8Array或Float32Array操作，无需解包 - 处理完需回传时，同样用
self.postMessage(result, [buffer])把所有权转回主线程
优先使用 SharedArrayBuffer 实现共享访问
当主线程和 Worker 需要频繁读写同一块数据（比如实时音频处理、流式图像帧更新），Transferable 的“交出-拿回”模式太重。SharedArrayBuffer 允许双方同时访问，延迟可压到 ~0.1ms 级别。
- 创建时需配合
Atomics保证线程安全，例如用Atomics.wait()/Atomics.notify()协作 - 必须在 HTTPS 或 localhost 环境下启用，且需设置跨域策略头
Cross-Origin-Embedder-Policy: require-corp - 适合场景：高频小粒度更新（如每帧修改像素）、多 Worker 协同处理分片数据
按需分片 + 流式处理
即使用了 Transferable 或 SharedArrayBuffer，一次性加载整块 GB 级缓冲区仍可能触发内存压力或 GC 暂停。更稳的做法是拆解为可控单元。
- 主线程将大 buffer 切成固定大小的子段（如每段 1MB），逐段 transfer 给 Worker
- Worker 用
ArrayBuffer.slice()或new Uint8Array(buffer, offset, length)定位操作区域 - 处理完一段立即回传结果或标记完成，避免堆积未释放内存
- 结合
requestIdleCallback或定时器控制吞吐节奏，防止 Worker 长时间独占 CPU
及时释放与复用内存
Worker 中不显式释放 ArrayBuffer，浏览器无法回收底层内存；反复 new ArrayBuffer 还可能引发碎片化。
- 处理完毕后，主动将引用设为
null，尤其对大 view（如Uint32Array） - 对重复使用的缓冲区，考虑在 Worker 内部维护一个简易池：
const pool = []，回收不用的 buffer 推入池中，下次pool.pop() || new ArrayBuffer(size) - 避免在 Worker 中长期持有主线程 transfer 过来的 buffer —— 不用就尽快转回或丢弃
