不能直接用navigator.hardwareConcurrency创建等量Worker，因其仅反映逻辑核心数而非最优并发数：盲目匹配会导致内存暴涨（每个Worker占4–6MB）、上下文切换开销增大、主线程通信阻塞；且该值在移动端Safari或Android WebView中可能失真（如固定返回2或undefined），需结合任务类型（CPU密集型取4–6个、I/O型取2–4个）、设备内存及运行时监控动态调整。
navigator.hardwareConcurrency 能读出逻辑核心数，但直接拿它当 Worker 数量用，八成会拖慢整体性能——尤其在低端设备或 I/O 密集场景下。
为什么不能直接用 navigator.hardwareConcurrency 创建等量 Worker
该值返回的是操作系统报告的逻辑处理器数量（比如 8 核 16 线程就返回 16），但它只是调度参考值，不是并发上限。浏览器本身对 Worker 的内存开销、上下文切换成本、主线程通信压力都有隐性限制：
- 移动端 Safari 在某些版本中固定返回
2或undefined，硬套会导致池子过小 - Android WebView 可能返回
2即使设备是 8 核，盲目扩容无意义 - 每个 Worker 默认占用 4–6MB 内存，开 16 个可能瞬间吃掉 100MB+，触发 GC 卡顿
- 主线程频繁
postMessage()传递大对象（如 HTML 字符串）会引发序列化瓶颈，Worker 多了反而排队等主线程
CPU 密集型 vs I/O 型任务的 Worker 数量怎么定
关键看任务“卡在哪”：是算得慢，还是等得久。
- CPU 密集型（如 HTML 字符串解析、正则批量替换、Base64 解码）：取
Math.min(navigator.hardwareConcurrency || 4, 6)，通常 4~6 个足够；超过 6 个，上下文切换开销开始盖过并行收益 - I/O 或轻量计算（如 fetch 后 JSON.parse、DOM 片段生成、简单字符串 split/join）：2~4 个即可；再多 Worker 不会加快网络响应，反而增加空转和调度负担
- 低端设备（
performance.memory?.jsHeapSizeLimit ）建议硬限为 3，不看 <code>hardwareConcurrency值
如何构建一个真正可用的 Worker 池
别一次性 new 出全部 Worker 并长期 hold 住。要用按需分配 + 空闲复用的轻量池：
立即学习“前端免费学习笔记（深入）”；
- 初始化池大小上限：
const poolSize = Math.max(2, Math.min(navigator.hardwareConcurrency || 4, 6)) - 用
Promise队列管理任务，Worker 完成后自动回归空闲队列，避免重复创建销毁 - 给每个 Worker 设置超时（如
setTimeout(() => worker.terminate(), 5000)），防止死循环或卡死阻塞整个池 - 共享内存（
SharedArrayBuffer）只在必须高频同步时启用，且服务端必须配齐Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin
最常被忽略的一点：Worker 数量不是静态配置项，而是需要结合 performance.memory、任务耗时统计、甚至用户设备类型（通过 navigator.userAgent 粗判）做运行时微调。硬编码 new Worker() 十次，不如动态维护一个 3–4 个 Worker 的健康池。
