Web Worker并行上限受CPU核心数、浏览器实现和硬件制约，推荐Worker池规模为4–8个并配合批量通信与主动降级策略。
Web Worker 的并行执行能力不是无限的，它受制于浏览器实现、操作系统调度、硬件资源（尤其是 CPU 核心数）以及运行时约束。所谓“边界测试”，不是指压测极限数值，而是厘清它在真实环境中能可靠并行到什么程度、哪些行为会触达瓶颈或失效。
并行数量的实际上限
浏览器对 Worker 实例数量没有统一硬性限制，但存在隐性天花板：
- Chrome 和 Edge 通常允许数百个 Worker 同时存活，但超过 50–100 个后，内存占用陡增，任务调度延迟明显升高，部分 Worker 可能被系统降级或暂停
- Firefox 对 Worker 线程数更保守，活跃 Worker 超过 20–30 个时，主线程消息接收可能开始出现丢帧或延迟
- 移动端 Safari 极其克制，实测常在 4–8 个 Worker 后就触发内存回收或静默终止
- 真正制约并行吞吐的不是“能创建多少个”，而是“有多少个能同时获得 CPU 时间片”——这取决于物理核心数与浏览器线程池策略，一般不超过 CPU 逻辑核心数 × 1.5
不能并行的“伪任务”场景
某些看似可并行的操作，Worker 并不能真正带来加速，甚至引入负优化：
- 频繁小数据通信：每毫秒 postMessage 一次、每次只传几个字节，通信开销远超计算本身。序列化/反序列化 + 主线程事件循环排队，反而比同步执行更慢
- I/O 密集型操作（如 fetch）：虽然 Worker 内可调用 fetch，但浏览器对同源并发请求数有全局限制（通常 6–10 个），多个 Worker 并发发起请求不会突破该限制，只是排队等待
- 依赖共享状态的任务：比如多个 Worker 都要读写 IndexedDB。DB 连接本身是主线程代理的，实际仍是串行访问，Worker 只是把阻塞从 UI 线程移到了 DB 等待队列
- 大量 DOM 操作回传：Worker 处理完数据后，若主线程需逐条更新数百个 DOM 节点，渲染压力仍在主线程，Worker 仅省去计算时间，整体卡顿依旧
资源耗尽的典型信号
当逼近边界时，会出现可观察的退化现象，而非直接报错：
- Worker 的
onmessage延迟显著增加（>100ms），即使主线程空闲 - 调用
self.postMessage()后，主线程长时间收不到回调（非丢失，是排队积压） - DevTools 的 Performance 面板中，Worker 线程显示大量“Idle”但 CPU 使用率持续高位，说明线程在争抢调度权
- 内存占用曲线陡升且不回落，尤其在 Chrome 的 Task Manager 中看到多个 “Worker” 进程 RSS 超过 100MB
- 部分 Worker 触发
error事件，错误信息为RangeError: Maximum call stack size exceeded或OutOfMemoryError（常见于递归处理未设深度限制）
可控并行的推荐实践
与其试探边界，不如按确定性策略设计：
- 采用 Worker Pool 模式：固定 4–8 个 Worker（匹配主流设备核心数），用队列分发任务，避免动态创建销毁开销
- 批量通信：合并多次小数据为单次大 payload，减少序列化次数；使用
Transferable（如 ArrayBuffer）零拷贝传递大数据 - 主动降级：检测
navigator.hardwareConcurrency，低端设备（≤2 核）默认禁用 Worker 或降为 1 个 - 设置超时与熔断：Worker 内部用
setTimeout或AbortSignal限时，主线程监听worker.onerror并自动 fallback 到主线程执行 - 避免嵌套 Worker：规范不支持 Worker 创建子 Worker（Chrome 曾实验性支持但已移除），所有并行必须由主线程统一管理
