navigator.hardwareConcurrency 返回的是操作系统报告的逻辑处理器数而非真实物理核心数，受沙箱限制、隐私策略、虚拟化环境及浏览器策略等多重干扰常不准甚至为1。
浏览器里拿不到真实的 CPU 物理核心数，navigator.hardwareConcurrency 返回的是逻辑处理器数量（即操作系统报告的可用线程数），且可能被限制、伪造或不准确。
为什么 navigator.hardwareConcurrency 常常不准或为 1
这个值由浏览器读取 OS 的调度器接口（如 Linux 的 /proc/cpuinfo、Windows 的 GetLogicalProcessorInformation）得出，但受多重干扰：
- 浏览器启动时未启用多进程沙箱（如某些 Electron 旧版本或禁用
--enable-features=PlzNavigate的 Chromium）会 fallback 到 1 - 隐私模式下部分浏览器（如 Firefox 95+、Safari 16.4+）默认返回
2或固定值以防止指纹追踪 - 容器/虚拟机环境（Docker、WSL2）中 OS 可能只暴露分配到的 vCPU，而非宿主机真实核心数
- Chrome 扩展或策略组（如企业版 Chrome 的
RestrictHardwareConcurrency策略）可强制设为 2 或 4
如何安全使用 navigator.hardwareConcurrency 做线程调度
它适合做“软提示”而非硬决策——比如预估 Web Worker 并发上限，但必须配合降级逻辑：
- 始终检查是否存在：
if ('hardwareConcurrency' in navigator)，IE 和部分老旧 WebView 不支持 - 不要直接
new Worker()×navigator.hardwareConcurrency：实际并发受内存、Worker 初始化开销、主线程阻塞影响更大 - 推荐取值范围：用
Math.min(4, Math.max(2, navigator.hardwareConcurrency || 2))—— 防止为 1 或过大（如 128 核服务器上起 128 个 Worker 反而拖慢） - 搭配
performance.memory（如有）粗筛内存压力：if (performance.memory?.totalJSHeapSize > 0.8 * performance.memory?.totalJSHeapSize)时主动减半 worker 数量
替代方案：用 Web Worker + performance.now() 实测并行吞吐
比依赖静态数值更可靠的方式是运行时探测：
立即学习“前端免费学习笔记（深入）”；
// 启动 N 个 worker，每个执行相同计算密集任务（如 1e6 次 Math.sin） // 测量总耗时，逐步增加 N 直到耗时开始非线性增长（即出现争抢） // 这个拐点通常接近有效并行度
注意点：
- 避免用
Date.now()，精度不够；必须用performance.now() - 任务需 CPU-bound（非 I/O 或 await），否则测的是调度延迟而非核心瓶颈
- 首次运行需 warmup：先跑一次丢弃结果，避免 JIT 编译干扰
- 移动端要额外加压测时间（
500ms+），因 thermal throttling 会导致后期核心降频
常见错误和兼容性陷阱
开发者常踩的坑集中在假设和边界上：
-
navigator.hardwareConcurrency在 iframe 中与顶层页面一致，但若跨域 sandbox iframe，该属性会被屏蔽（返回undefined） - Vite / Webpack Dev Server 默认启用
worker-loader时，热更新可能意外销毁 worker 引用，导致hardwareConcurrency推导的 worker 数量错乱 - Service Worker 环境中无法访问
navigator.hardwareConcurrency（navigator对象不可用） - Electron 13+ 默认禁用该 API，需在
webPreferences中显式开启：{ webPreferences: { nodeIntegration: false, contextIsolation: true, enableWebSQL: false } }不影响，但需确认未启用disable-features=HardwareConcurrency
真正关键的不是数字本身，而是理解它反映的是「当前运行时环境愿意给你多少并行能力」——这个能力随时可能被系统策略、电池状态、甚至用户打开的另一个标签页吃掉。别把它当 CPU 规格书读。
