web worker并发数应依据硬件逻辑核心数动态设定，初始池大小建议为navigator.hardwareconcurrency值的1–2倍且不超过8；需监控处理耗时与排队延迟，结合页面可见性及卸载时机优化生命周期管理。
Web Worker 的并发限制不是硬性标准，而是由浏览器实现、设备硬件和任务特性共同决定的动态边界。盲目增加 Worker 数量不等于性能提升，反而容易引发资源争抢、上下文切换开销和内存压力。关键在于找到“够用且不过载”的平衡点。
依据 CPU 核心数动态设定 Worker 上限
现代浏览器可通过 navigator.hardwareConcurrency 获取逻辑核心数，这是最可靠的起点。 - 多数桌面端设备返回 4–16；移动端通常为 2–8。 - 建议初始 Worker 池大小设为该值的 1–2 倍，例如：const maxWorkers = Math.min(8, navigator.hardwareConcurrency || 4);
- 对于轻量计算（如每条数据处理耗时 避免“线程爆炸”带来的三类隐性开销 过多 Worker 并不加速，反而拖慢整体： - 内存占用翻倍：每个 Worker 独立 V8 实例，基础内存约 4–6MB，10 个即占用 40MB+； - 调度开销上升：OS 线程切换成本在高并发时显著，尤其在低核数设备上； - 通信竞争加剧：大量 postMessage 同时触发，主线程消息队列堆积，反致响应延迟。
按任务类型差异化分配资源
并非所有计算都适合均分到多个 Worker： - CPU 密集型任务（如矩阵运算、加密）：优先绑定到物理核心，Worker 数 ≈ 物理核数，禁用超线程冗余； - I/O + CPU 混合型任务（如文件分片解析）：可略超核心数（如 ×1.5），利用等待 I/O 的空闲周期； - 短时高频任务（如实时传感器数据滤波）：用单 Worker + 队列批处理，比启多个更轻量。运行时监控与弹性回收
静态配置不够，需结合实际负载调整： - 在 Worker 内记录执行耗时与空闲时长，主线程定期评估：若平均空闲 >60%，说明资源过剩；若排队延迟 >100ms，可能需扩容（但上限仍受 hardwareConcurrency 约束）； - 页面可见性变化时主动暂停非关键 Worker（document.hidden 触发）； - 卸载前调用 terminate()，防止后台常驻消耗电量或内存。不复杂但容易忽略。
