navigator.hardwareConcurrency 返回设备逻辑核心数，用于动态分配Web Worker数量，推荐取值Math.min(navigator.hardwareConcurrency||4,8)，需兼容旧版浏览器及隐私模式限制，并结合任务类型与设备实际性能调整。
HardwareConcurrency 是 HTML5 提供的只读属性，位于 navigator 对象下，用于返回用户设备的逻辑 CPU 核心数（包括超线程核心），是合理分配 Web Worker 任务数量的重要依据。
获取核心数并验证可用性
并非所有浏览器都支持该属性，需做兼容性判断：
- 直接访问
navigator.hardwareConcurrency，现代 Chrome、Firefox、Edge、Safari（16.4+）均已支持 - 若返回
undefined或1（某些旧版或隐私模式下可能被限制），建议 fallback 到保守值，如2或4 - 注意：部分浏览器（如 Safari 在无痕模式）会返回
1以保护指纹隐私，不可当作真实核心数使用
按核心数动态创建 Worker 实例
避免硬编码 Worker 数量，应根据 hardwareConcurrency 动态决定并发 Worker 数量：
- 推荐取值为
Math.min(navigator.hardwareConcurrency || 4, 8)—— 既利用多核，又防止在高核心数设备上创建过多 Worker 导致内存/调度开销 - 例如：检测到 12 核，可启动 8 个 Worker；检测到 2 核，则只启 2 个
- 每个 Worker 应处理独立数据块（如数组分片），避免共享状态和频繁通信
结合任务粒度与负载均衡
仅靠核心数还不够，需匹配实际任务特性：
立即学习“前端免费学习笔记（深入）”；
- CPU 密集型任务（如图像处理、加密计算）适合严格按核心数分配；I/O 密集型（如 fetch + 解析）则不宜满载，可略少于核心数
- 使用
Worker.postMessage()分发等长数据块，或借助Transferable（如ArrayBuffer）零拷贝传递大数组提升效率 - 可引入简单队列机制：主页面维护待处理任务队列，Worker 完成后主动请求新任务，实现动态负载均衡
注意事项与常见陷阱
实际使用中容易忽略的关键点：
- Worker 文件路径必须符合同源策略，且不能是
blob:或data:URL（除非用URL.createObjectURL(new WorkerScript)） - 移动端设备核心数通常为 4–8，但热节流严重，建议上限设为
4并监听beforeunload或pagehide及时terminate() - 不要假设
hardwareConcurrency精确反映并行能力 —— 虚拟机、容器环境或系统资源紧张时，实际性能可能远低于理论值
