navigator.hardwareconcurrency仅是逻辑核心数参考值，不能直接用作web worker数量；需结合内存、任务类型、系统负载动态调整，并设置弹性调度与降级策略。

直接看结论：navigator.hardwareConcurrency 只是参考值，不能直接当 Worker 数量用；硬套它创建线程池，轻则浪费资源，重则在低端设备上引发卡顿甚至崩溃。

为什么不能直接用 navigator.hardwareConcurrency 作线程数

这个值反映的是逻辑核心数（比如超线程开启时可能返回 12），但不等于可用并发能力。浏览器本身有线程调度开销，Worker 初始化成本高，且每个 Worker 占用独立内存和事件循环。实测中，即使 navigator.hardwareConcurrency === 12，在 2GB 内存的 Android 设备上开 8 个 Worker 就会导致频繁 GC 和主线程抖动。

• 它不区分 CPU 密集型还是 I/O 型任务 —— 图像处理和 JSON 解析对线程数的敏感度完全不同
• 它不感知内存压力 —— performance.memory 在部分 Chrome 版本可用，但很多低端设备根本没这个 API
• 它无法反映当前系统负载 —— 用户同时开着十几个标签页时，你按 8 核配 8 个 Worker，实际能抢到的 CPU 时间片可能不足 20%

Math.min(navigator.hardwareConcurrency || 4, 6) 是个安全起点，但不是终点

这个表达式常见于 demo 和脚手架，作用是兜底防错，但它只解决“不崩”，不解决“高效”。真正落地时必须叠加业务判断：

• CPU 密集型任务（如 WebAssembly 音视频转码、图像滤镜）：取 Math.min(navigator.hardwareConcurrency || 4, 4) 更稳妥，超过 4 个 Worker 后吞吐提升极小，但内存占用线性增长
• I/O 或轻计算（如分块解析大 JSON、正则批量匹配）：2~3 个足够，再多只是增加消息队列等待时间
• 微前端场景（如 qiankun）：主应用应统一管理全局 Worker 池，避免各子应用各自创建，否则 hardwareConcurrency === 8 时可能累积出 20+ 个 Worker

动态调节的关键不在“数量”，而在“调度时机”

静态池大小注定会过时。更实用的做法是让池具备弹性：初始化时设上限，运行中按需伸缩。

• 用 Promise 队列 + 空闲 Worker 轮询代替“预创建全量 Worker”：新任务来时，优先分配给空闲 Worker；无空闲时，才考虑是否扩容（比如当前负载 > 80% 持续 3 秒）
• 监听 beforeunload 和微应用 unmount 钩子，主动调用 worker.terminate()，QuaggaJS 的泄漏案例就源于这一步缺失
• 对长时间无响应的 Worker（例如 postMessage 后 5s 未回传），强制 terminate() 并重建 —— 这比等它自己卡死强得多

容易被忽略的兼容性与降级路径

navigator.hardwareConcurrency 在 Safari 15.4 以下、旧版 Firefox 中返回 undefined，而某些国产浏览器（如 UC 13.x）虽返回数字，但实际 Worker 并发能力远低于该值。

• 必须有 fallback：推荐默认值设为 4，而不是 1 或 2 —— 多数现代设备至少能稳跑 4 个轻量 Worker
• 避免在 Worker 构造函数里直接依赖 hardwareConcurrency：主线程算好再传参，Worker 内部不应再查这个值
• 当检测到内存紧张（performance.memory?.jsHeapSizeLimit 存在且剩余

真正难的不是算出一个数字，而是让线程池在不同设备、不同任务、不同内存状态下都“不抢资源、不拖主线程、不悄悄吃内存”。hardwareConcurrency 只是一把尺子，但你要量的不是 CPU 核心，是用户此刻的真实体验。