node.js 默认为单线程事件循环模型，无法自动利用多核 cpu；需通过进程级并行（如 cluster 模块或 pm2 管理的多实例）显式启用多核能力，但需注意任务可并行性、ipc 开销及适用场景。
node.js 默认为单线程事件循环模型，无法自动利用多核 cpu；需通过进程级并行（如 cluster 模块或 pm2 管理的多实例）显式启用多核能力，但需注意任务可并行性、ipc 开销及适用场景。
Node.js 的核心设计基于单线程事件循环（Event Loop），这使其在 I/O 密集型场景下高效且轻量，但也意味着单个 Node.js 进程默认仅绑定一个 CPU 核心。当运行 CPU 密集型任务（如数学计算、图像处理、加密解密）时，即使系统拥有 8 核 16 线程，单进程 Node.js 也只能使用其中 1 个逻辑核心，造成大量算力闲置——这正是 The Computer Language Benchmarks Game 中 Node.js 在 CPU 基准测试中显著落后于 Go 等多线程/协程原生并发语言的根本原因。
要真正释放多核潜力，必须采用进程级并行（Process-Level Parallelism），而非试图在单进程中“多线程化”。Node.js 官方提供了两种主流方案：
✅ 方案一：使用内置 cluster 模块（推荐用于 HTTP 服务）
cluster 模块允许主进程（master）派生多个工作进程（workers），共享同一端口，并由操作系统内核自动负载均衡 TCP 连接。适用于 Web 服务器类场景：
const cluster = require('node:cluster');
const http = require('node:http');
const { cpus } = require('node:os');
if (cluster.isPrimary) {
console.log(`Primary ${process.pid} is running`);
// 衍生与 CPU 核心数相同的工作进程
for (let i = 0; i < cpus().length; i++) {
cluster.fork();
}
cluster.on('exit', (worker) => {
console.log(`Worker ${worker.process.pid} died`);
cluster.fork(); // 自动重启崩溃进程（生产环境建议加限频）
});
} else {
// 工作进程：处理实际请求
http.createServer((req, res) => {
res.writeHead(200);
res.end('Hello from worker ' + process.pid);
}).listen(3000);
console.log(`Worker ${process.pid} started`);
}⚠️ 注意：
cluster仅对 网络请求分发有效，不适用于纯计算型任务的自动拆分。若你的业务逻辑是同步 CPU 绑定型（如fibonacci(45)循环计算），每个 worker 仍会阻塞自身事件循环——此时需结合worker_threads或进程间任务调度。
✅ 方案二：进程外编排（适合任意负载类型）
使用进程管理器（如 PM2）启动多个独立 Node.js 实例，并通过反向代理（Nginx）或负载均衡器分发请求：
# 启动 4 个实例，自动匹配 CPU 核心数 pm2 start app.js -i 4 # 或启用智能负载均衡（基于 CPU 使用率） pm2 start app.js -i max --balance
该方式更灵活，支持跨机器部署，且避免了 cluster 模块的主进程单点依赖问题；但需自行处理进程间状态共享（如 session、缓存）——应使用 Redis 等外部存储替代内存变量。
❌ 不推荐的做法
- 试图用
setTimeout(fn, 0)或setImmediate()“模拟多线程” → 仍在同一事件循环中，无法提升 CPU 利用率； - 盲目引入
worker_threads处理简单 HTTP 请求 → 线程创建/通信开销远超收益，仅适合长时同步计算且数据可序列化的小规模任务； - 未评估任务可并行性即堆砌进程 → 若业务逻辑强依赖全局状态或顺序执行（如串行订单处理），多进程反而引发竞态或一致性问题。
总结
Node.js 要达到接近 Go 的多核利用率，关键不在语言本身，而在架构设计：
? 对 I/O 密集型服务（API、网关），cluster 或 PM2 多实例是成熟、低风险的选择；
? 对 CPU 密集型批处理，应将重计算模块下沉至 Rust/WASM 或子进程（child_process.fork），保持主线程响应性；
? 永远先测量（top / htop / process.cpuUsage()）再优化——90% 的性能瓶颈实际源于低效算法或阻塞 I/O，而非 CPU 核心未被利用。
