不能直接用 navigator.hardwareConcurrency 作为线程并发数，需结合任务类型、内存状况和网络条件动态调整：CPU密集型取 min(cores,6)，I/O型用2～4个，低端设备限3～4，并通过Worker池与RTT联动调控。
不能直接用 navigator.hardwareConcurrency 的返回值作为线程并发数，它只是逻辑核心数的参考值，真实可用并发需结合任务性质、内存状况和运行时反馈综合决策。
理解 hardwareConcurrency 的真实含义
该属性返回的是设备逻辑处理器数量（如 4 核 8 线程返回 8），代表并行执行能力的理论上限，不是推荐创建的 Worker 数量。它在部分旧浏览器或安卓 WebView 中可能为 undefined 或固定小值（如 2），需做兼容兜底：const cores = navigator.hardwareConcurrency || 4;
注意：Firefox 等浏览器可能人为模糊返回值（如恒定返回 4）以防止指纹追踪，因此不可用于精确性能预估。
按任务类型设定合理并发区间
异步渲染任务通常混合了计算与 I/O，需分类处理：
- CPU 密集型子任务（如 Canvas 图形合成、滤镜计算、坐标批量转换）：建议取
Math.min(cores, 6)，上限不超 6，避免上下文切换开销反超收益 - I/O 或轻量计算型（如 DOM 属性读取、样式计算、JSON 解析）：2～4 个 Worker 足够，再多几乎无加速效果
- 内存敏感场景（低端 Android、iOS Safari）：即使
cores === 8，也应强制限制为 3～4，并可结合navigator.deviceMemory辅助判断（如deviceMemory < 2时降为 2）
构建可监控的 Worker 池机制
不推荐一次性创建固定数量 Worker 并长期驻留。更优做法是实现带状态感知的轻量池：
- 初始化池大小上限：
const poolSize = Math.min(navigator.hardwareConcurrency || 4, 6); - 采用 Promise 队列 + 空闲 Worker 轮询调度，避免频繁创建/销毁开销
- 对单个 Worker 执行耗时超过阈值（如 500ms）的任务主动标记为“可疑”，后续降级至主线程执行或重启该 Worker
- 监听
performance.memory（若可用）或 Worker 自报内存使用量，触发动态缩容
结合网络与渲染节奏做二次调节
异步渲染常依赖资源加载，可联动 navigator.connection.rtt 做协同调控：
- rtt ≤ 50ms（优质网络）：允许池满载运行，优先保障计算并发
- 50ms < rtt ≤ 150ms（中等网络）：保留 1～2 个 Worker 空闲，用于响应用户交互中断请求
- rtt > 150ms（弱网）：主动暂停非关键渲染任务，将并发数降至 1～2，避免抢占主线程资源影响首屏帧率
不复杂但容易忽略。
