Web Worker 能否提升性能取决于是否与多核 CPU 合理适配，需结合硬件、浏览器限制和任务特性动态匹配；单核下使用反而更慢，Worker 数量不宜超过 navigator.hardwareConcurrency 返回值，且仅计算密集型、可分割、无 DOM 依赖的任务才适合。

Web Worker 能否真正提升性能，关键不在“开了几个”，而在于是否与多核 CPU 架构形成合理适配。它不是越多越好，也不是简单按核心数一对一配置，而是需要结合硬件能力、浏览器限制和任务特性做动态匹配。

多核是并行的前提，单核上用 Worker 可能反而更慢

Worker 的价值建立在物理多核基础上。操作系统调度线程时，只有在多个逻辑核心可用的情况下，Worker 才能被真正分配到不同核心上并行执行。如果设备是单核 CPU（或虚拟机/旧设备仅暴露 1 个逻辑核），所有 Worker 实际仍靠时间片轮转，加上主线程与 Worker 之间通信开销（序列化、上下文切换），整体耗时可能比直接在主线程计算还长。

• 可通过 navigator.hardwareConcurrency 获取当前设备暴露的逻辑核心数（如返回 4 或 8）
• 低于 2 的值基本意味着无并行收益，谨慎启用 Worker
• 注意：该值反映的是浏览器可调度的逻辑核数，不等于物理核心数，但足以作为并行能力参考

Worker 数量不宜超过逻辑核心数

理想情况下，Worker 数量应 ≤ navigator.hardwareConcurrency 返回值。超出后，系统需频繁做线程调度和上下文切换，CPU 缓存命中率下降，内存带宽争抢加剧，实际吞吐反而降低。

• 例如：8 核设备创建 12 个 Worker，其中 4 个长期处于等待状态，空转消耗资源
• 浏览器本身也有限制——多数现代浏览器对单页 Worker 总数设为 50–100 个，但这只是上限，非推荐值
• 实测表明，4–8 个 Worker 在多数桌面/高端移动设备上已接近性能拐点

任务类型决定是否值得拆分

并非所有计算都适合 Worker。只有计算密集型、可分割、无 DOM 依赖的任务才从中受益。IO 密集型（如 fetch、localStorage）或短时任务（

• 适合场景：图像滤镜批量处理、大型数组排序/聚合、加密解密、Wasm 数值模拟
• 不适合场景：简单表单校验、轻量级状态更新、DOM 元素样式修改
• 建议先用 Performance API 测量主线程耗时，若某函数稳定 >50ms 且纯计算，再考虑 Worker 拆分

通信与内存模型影响实际效率

Worker 与主线程之间不是共享内存，而是通过消息传递。默认使用结构化克隆（深拷贝），大数据量传输代价高。要真正释放多核潜力，需配合现代机制：

• 传输 ArrayBuffer 时使用 Transferable（如 postMessage(buf, [buf])），实现零拷贝移交
• 多个 Worker 协同计算时，可用 SharedArrayBuffer + Atomics 实现低延迟共享内存（需 HTTPS 环境）
• 避免高频小消息：把多次计算结果合并后一次性返回，减少通信频次