Node.js 最让人困惑的一点是：它明明是单线程执行 JavaScript，为什么还能处理大量并发请求？原因在于 Node.js 并不是靠多线程来应对并发，而是采用事件驱动架构。主线程只负责执行同步代码，遇到文件读取、数据库查询、网络通信这类 I/O 操作时，会立即把任务交给底层模块，然后继续处理后续代码。一旦 I/O 完成，系统会通过事件通知的方式把回调函数重新交还给主线程执行。这种机制让单个进程可以同时维持成千上万个连接，而不会因为等待响应白白占用 CPU 和内存。
一、Event Loop 的分阶段运行机制
Node.js 的 Event Loop 并不是简单地不断从队列中取出回调执行，而是把回调按照类型分配到不同阶段。官方文档中，Event Loop 每一轮迭代包含以下几个阶段：timers 阶段执行 setTimeout 和 setInterval 的到期回调；pending callbacks 阶段处理某些系统操作的回调；idle 和 prepare 阶段仅由内部使用；poll 阶段是核心阶段，负责获取新的 I/O 事件并执行与 I/O 相关的回调；check 阶段执行 setImmediate 回调；close callbacks 阶段处理 socket 或句柄关闭的事件。
理解分阶段的目的是为了准确预测回调的执行顺序。很多开发者以为 setTimeout(fn, 0) 一定比 setImmediate(fn) 先执行，事实并非如此。当代码在模块顶层直接调用这两个函数时，如果 Event Loop 正停在 poll 阶段等待事件，它会先检查是否有 setImmediate 回调，因此 setImmediate 可能会比 setTimeout 更早执行。可一旦把调用放进一个 I/O 回调内部，结果又会反转，因为 I/O 回调执行完毕后，Event Loop 会进入 check 阶段，此时 setImmediate 必定在下一轮 timers 阶段之前运行。
下面这段代码展示了同一时刻注册 setTimeout 和 setImmediate 时的执行差异。由于 Event Loop 首次进入 poll 阶段时还没有到期的定时器，它会优先处理 check 阶段的 setImmediate 回调。
setTimeout(() => {
console.log('setTimeout');
}, 0);
setImmediate(() => {
console.log('setImmediate');
});
实际运行结果并不固定，受进程启动时间和系统负载影响。要稳定观察差别，应该把两个调用放到一个 I/O 回调里，例如读取文件后执行，这时 setImmediate 会稳定先于 setTimeout 打印。
二、libuv 与线程池如何实现非阻塞 I/O
Node.js 之所以能把 I/O 操作交给系统异步处理，主要依赖 libuv 这个跨平台的异步 I/O 库。在 Linux 上，libuv 使用 epoll；在 macOS 和 BSD 系统上使用 kqueue；在 Windows 上则使用 IOCP。这些系统调用允许进程监听多个文件描述符的可读或可写事件，当某个连接有数据到达时，内核会通知 libuv，libuv 再把对应的回调加入事件队列。整个过程不需要为每个连接创建独立线程。
不过并非所有 I/O 都能通过 epoll 这类机制完成。例如文件系统操作在多数平台上没有统一的异步接口，libuv 会使用内部的线程池来执行这些任务。默认线程池大小为 4，可以通过环境变量 UV_THREADPOOL_SIZE 调整。像 fs.readFile、fs.writeFile、dns.lookup 等操作都会占用线程池。而网络 I/O 如 http 请求、TCP 连接则直接依赖 epoll/kqueue，不会消耗线程池资源。
下面是一个异步读取文件的例子。调用 fs.readFile 后，主线程会继续执行后面的 console.log，而不会等待文件内容返回。读取完成后，libuv 会通过线程池中的某个线程拿到结果，并把回调推入 poll 阶段等待执行。
const fs = require('fs');
fs.readFile('./data.txt', 'utf8', (err, data) => {
if (err) {
console.error(err);
return;
}
console.log(data);
});
console.log('文件读取已经发起');
这个例子中，先打印的是“文件读取已经发起”，随后才会输出文件内容。如果文件很大，线程池中的线程会被占用，过多的大文件读取可能导致其他依赖线程池的操作排队，这是后续优化时需要留意的点。
三、微任务与宏任务的执行顺序
除了分阶段队列，Node.js 还维护了微任务队列。微任务包括 process.nextTick 回调以及 Promise.then、async/await 产生的回调。微任务的优先级高于宏任务，并且每个宏任务执行完毕后、进入下一个阶段之前，Event Loop 都会清空当前微任务队列。process.nextTick 的优先级又高于普通 Promise 微任务，它会在当前操作结束后立即执行，哪怕这意味着递归调用 nextTick 会饿死 Event Loop。
很多异步顺序问题都源于对微任务和宏任务边界理解不清。比如把 setTimeout 和 Promise.resolve().then 放在一起，微任务总是先运行，因为当前执行栈清空后会先处理微任务，然后才轮到 timers 阶段里的 setTimeout。下面这段代码可以直观验证这一顺序。
Promise.resolve().then(() => {
console.log('Promise 回调');
});
process.nextTick(() => {
console.log('nextTick 回调');
});
setTimeout(() => {
console.log('setTimeout 回调');
}, 0);
输出顺序为：nextTick 回调、Promise 回调、setTimeout 回调。虽然 setTimeout 在代码中最先出现，但因为宏任务排在微任务之后，它必须等到当前 Event Loop 进入 timers 阶段才会执行。理解这个顺序对处理异步流程、避免竞态条件非常重要。
四、如何避免阻塞事件循环
事件驱动架构的优势建立在主线程始终能快速响应事件的基础上。一旦有 CPU 密集任务长时间占用主线程，所有 I/O 回调、定时器、微任务都会被推迟，整个服务的并发能力会急剧下降。典型阻塞场景包括大数组循环计算、JSON 解析超大对象、递归算法等。这些任务本身不是 I/O，无法交给 libuv 异步处理，只能在主线程中同步执行。
对于短时间能完成的计算，可以通过拆分任务让出主线程。例如把一个大循环拆成多个小批次，用 setImmediate 或 setTimeout 在批次之间让 Event Loop 有机会处理其他事件。更彻底的办法是使用 worker_threads 模块，把 CPU 密集计算移动到工作线程中，主线程只负责接收结果。Node.js 还提供了 child_process 模块，可以启动独立进程处理繁重任务，不过进程间通信成本高于线程。
另一个常见阻塞来源是同步 API 的误用。例如 fs.readFileSync、fs.writeFileSync、child_process.execSync 等，它们会完全阻塞主线程直到操作完成。在服务器代码中，这些同步方法只适合在启动阶段加载配置文件，不应出现在请求处理路径中。下面这个例子演示了如何使用 setImmediate 将大任务分批执行，避免长时间卡死。
function processLargeArray(items, batchSize, done) {
let index = 0;
function nextBatch() {
const end = Math.min(index + batchSize, items.length);
for (let i = index; i < end; i++) {
items[i] = items[i] * 2;
}
index = end;
if (index < items.length) {
setImmediate(nextBatch);
} else {
done();
}
}
nextBatch();
}
注意代码中使用 setImmediate 而不是 process.nextTick 来调度下一批次。如果使用 nextTick，微任务会在当前阶段反复插入，导致 Event Loop 无法进入后续阶段，实际上仍然会饿死 I/O 事件。
五、事件驱动架构的适用场景与局限
Node.js 的事件驱动架构最适合 I/O 密集型应用，例如实时聊天服务、API 网关、数据流处理、消息推送等。这些场景中，程序的大部分时间都在等待网络或磁盘响应，主线程的计算开销很小。事件驱动模型可以让一个 Node.js 进程同时服务几万甚至更多连接，配合集群模块还能利用多核 CPU 扩展吞吐量。
但事件驱动架构并非银弹。对于图像处理、视频转码、机器学习推理、复杂数学计算等 CPU 密集型任务，单线程模型会面临严重瓶颈。即便使用 worker_threads 缓解，仍然需要考虑数据传输和同步成本。此外，事件驱动的异步模型会让代码流程变得分散，回调嵌套、错误处理、上下文传递都比同步代码更复杂。虽然 async/await 显著改善了可读性，但深层异步链路中的异常传播依然需要谨慎设计。
对比传统的多线程阻塞模型，Node.js 的优势在于更低的资源占用和更高的连接并发能力，但在长耗时计算上不如 Java、Go 等语言直观。开发者需要根据业务特征选择技术栈：如果核心矛盾是等待 I/O 而非计算，事件驱动架构能够用很小的硬件成本获得很好的吞吐表现；如果业务中大量存在 CPU 密集操作，就应该把这些模块拆分为独立服务或改用更适合的语言。
Node.js事件驱动Event Loop修改时间：2026-10-03 12:03:54