navigator.hardwareConcurrency 返回逻辑处理器数，但需结合任务类型、内存和兼容性动态设定Worker数量，旧版浏览器应兜底为4，CPU密集型取4~6个，I/O型取2~4个，共享内存需CORS策略支持。
可以直接用 navigator.hardwareConcurrency 获取设备逻辑处理器数量，但不能直接按这个数创建等量 Worker——它只是调度参考值，不是最优并发数。关键在于结合任务类型、内存状况和浏览器兼容性做动态适配。
正确读取并兼容 fallback 值
该属性在部分旧版或 WebView 中可能返回 undefined，必须做兜底处理：
- 始终检查是否存在：
const cores = navigator.hardwareConcurrency || 4; - 移动端 Safari 16.4+、Chrome（Android/桌面）、Firefox、Edge 均支持；部分安卓 WebView 可能固定返回 2 或 undefined
- 避免直接赋值给 Worker 数量，仅作为上限依据之一
按任务类型合理设定 Worker 数量
CPU 核心数 ≠ 最佳 Worker 数。盲目拉满反而引发内存压力与上下文切换开销：
- CPU 密集型任务（如 HTML 字符串解析、图像滤镜、加密）：取
Math.min(cores, 4)到Math.min(cores, 8)，通常 4~6 个足够 - I/O 或轻量计算（如 JSON 解析、正则替换）：2~4 个 Worker 即可，再多几乎无收益
- 低端设备（如内存 cores === 8，也建议硬限为 3~4，并可结合
performance.memory?.jsHeapSizeLimit辅助判断
用 Worker 池实现按需调度
不推荐一次性创建固定数量 Worker 并长期持有。更优做法是构建轻量池，运行时动态分配：
- 初始化池大小上限：
const poolSize = Math.max(2, Math.min(navigator.hardwareConcurrency || 4, 6)); - 用 Promise 队列管理任务，空闲 Worker 轮询领取，减少创建/销毁开销
- 对超时或无响应的 Worker 主动终止并重建，防止内存泄漏或卡死
- 示例简写：
const workers = Array.from({ length: poolSize }, () => new Worker('task.js'));
进阶协同：SharedArrayBuffer + Atomics
当多个 Worker 需高频共享数据（如分段解析大型 HTML 字符串），可启用共享内存提升效率，但有前提条件：
- 服务端必须返回
Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp - 主线程创建
SharedArrayBuffer，通过postMessage(..., [sharedBuf])传递引用 - Worker 使用
Int32Array等视图操作缓冲区，所有读写必须经Atomics.load()/Atomics.store() - 用
Atomics.wait()和Atomics.notify()实现 Worker 间同步，避免竞态
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
