web worker 性能提升需满足低通信开销和任务足够重，推荐用 typedarray + arraybuffer + transferable 实现零拷贝，子数组长度超 1000 才显优势，1000–50000 用单 worker，超 5 万可多 worker 分片，但须避免同步依赖与 dom 操作。
Web Worker 的性能提升不是自动发生的，关键在于通信开销是否被真正压低，以及并行任务是否足够“重”——轻量计算反而因消息传递拖慢整体速度。
通信开销：结构化克隆 vs 零拷贝
主线程与 Worker 之间默认使用结构化克隆算法序列化数据。对普通数组、对象、Map 等类型，这会触发深拷贝，内存占用高、耗时明显。尤其当传输百万级数字数组时，拷贝本身可能比计算还慢。
- ✅ 推荐做法：用 TypedArray + ArrayBuffer + Transferable 实现零拷贝。主线程移交 buffer 所有权后，Worker 直接操作同一块内存视图，无复制成本
- ⚠️ 注意移交后主线程原数组立即失效，不可再读写；需靠 Worker 返回新视图或元信息重建
- ❌ 避免频繁发送小对象（如每帧传一个坐标点），改用批量打包或状态差分更新
并行收益阈值：不是越多越快
并行提速有明确下限。实测表明：
- 子数组长度 时，Worker 创建+通信开销 > 并行收益，应退回到主线程原生方法（如
Array.prototype.sort()） - 1000–50000 区间适合单 Worker 处理，避免调度负担
- 超 5 万数据才值得启用多 Worker 分片；但 Worker 数量不宜超过
navigator.hardwareConcurrency（通常为 CPU 逻辑核数）
算法适配比线程数量更重要
并行效率不取决于开了几个 Worker，而取决于任务能否真正拆解、独立执行、避免同步等待。
- 适合场景：归并排序分段合并、图像像素滤波、FFT 分块计算、大文件哈希分块校验
- 不适合场景：依赖前序结果的链式计算（如递推数列）、频繁跨段读写、需 DOM 参与的渲染逻辑
- 关键设计：预分配共享缓冲区，各 Worker 按
{buffer, byteOffset, length}创建独立视图，结果写入指定区域，减少返回数据量
真实性能拐点参考（基于 2026 年主流设备实测）
以 1000 万整数排序为例：
- 主线程直接 sort()：约 480ms（V8 已深度优化）
- 单 Worker + 结构化克隆传数据：约 620ms（通信拖累明显）
- 单 Worker + Transferable + TypedArray：约 390ms
- 4 Worker 分片 + Transferable + 归并整合：约 180ms，主线程全程保持 60fps
