Node.js之所以能够在单线程环境下高效处理大量并发请求，其核心秘诀在于底层libuv库所提供的事件循环机制。事件循环并非一个简单的无限循环，而是一个被精细划分为多个阶段的复杂状态机。在每一个阶段中，Node.js都会执行特定类型的回调函数，从而实现非阻塞I/O和异步任务的调度。理解这六个阶段的运转规律，对于编写高性能、无阻塞的Node.js应用程序至关重要。
事件循环的核心阶段解析
事件循环的起点是timers阶段。在这个阶段中，系统会检查并执行由setTimeout和setInterval设置的定时器回调。需要特别强调的是，定时器所设定的时间参数并非精确的执行时间点，而是回调函数最早可以被执行的时间阈值。只有当系统时间达到或超过该阈值，并且事件循环恰好轮转到timers阶段时，对应的回调才会被推入执行栈。这种设计是为了避免在高频事件处理中频繁检查时间而带来的性能损耗。
// 演示timers阶段与同步代码的执行顺序
setTimeout(() => {
console.log('定时器回调：在timers阶段执行');
}, 0);
// 同步代码会优先于定时器回调执行
console.log('同步代码：最先执行');
紧随其后的是pending callbacks阶段与idle、prepare阶段。pending callbacks阶段主要负责执行那些被延迟到下一次循环的系统级操作回调，例如某些TCP连接错误或底层文件系统的异常回调。这些回调通常由操作系统底层触发，普通业务逻辑极少直接涉及。而idle和prepare阶段则是libuv内部使用的准备环节，主要用于内部状态的初始化与资源调度，开发者在应用层无需也无法直接干预这两个阶段的执行逻辑。
poll阶段是整个事件循环中最为核心且耗时的阶段。它承担着两项关键任务：首先是执行与I/O操作相关的回调，例如文件读取完成或网络请求返回数据的回调；其次是计算下一个定时器到期所需的时间，并在没有待处理I/O事件时进行适当的阻塞等待。如果poll队列中存在可执行的回调，系统会依次执行它们直到队列清空或达到系统设定的上限。若队列为空，系统则会根据是否存在setImmediate回调或已到期的定时器，来决定是直接进入check阶段还是返回timers阶段。
收尾阶段与执行顺序机制
当poll阶段的任务处理完毕或满足跳出条件后，事件循环会进入check阶段。这个阶段是专门为setImmediate这一Node.js特有API设立的。与setTimeout不同，setImmediate的回调不需要等待时间阈值，只要poll阶段结束，这些回调就会立即被执行。这使得开发者可以将某些不需要立即阻塞当前代码执行，但又希望在当前I/O事件处理完毕后尽快执行的任务，安排在check阶段运行，从而优化任务的执行优先级。
// 演示poll阶段与check阶段的交互
const fs = require('fs');
// 文件读取的I/O回调会在poll阶段执行
fs.readFile('./data.txt', 'utf8', (err, data) => {
console.log('I/O回调：在poll阶段执行');
// setImmediate回调会在随后的check阶段执行
setImmediate(() => {
console.log('setImmediate回调：在check阶段执行');
});
});
事件循环的最后一个阶段是close callbacks阶段。当应用程序中的某些资源被显式关闭时，例如调用了socket.destroy()或者服务器停止监听，相关的关闭事件回调就会在这个阶段被集中执行。这为开发者提供了一个清理资源、解除绑定的最后时机，确保在连接彻底断开或进程退出前，所有相关的收尾工作都能得到妥善处理。
这六个阶段并非孤立存在，而是按照严格的顺序依次流转。每一轮完整的事件循环都会从timers阶段开始，依次经过pending callbacks、idle/prepare、poll、check，最终到达close callbacks阶段。如果某个阶段当前没有待处理的任务，事件循环会迅速跳过该阶段，继续向前推进。只有当所有阶段的任务都被处理完毕，且没有任何挂起的异步操作时，Node.js进程才会正常退出。
| 阶段名称 | 处理任务类型 | 典型API |
|---|---|---|
| timers | 定时器到期回调 | setTimeout、setInterval |
| pending callbacks | 系统操作延迟回调 | 底层错误回调 |
| idle/prepare | 内部准备任务 | 无用户层API |
| poll | I/O操作回调 | fs.readFile、网络请求回调 |
| check | 立即执行回调 | setImmediate |
| close callbacks | 关闭事件回调 | socket close、process exit |
微任务队列与常见认知误区
在探讨事件循环时，许多开发者容易将process.nextTick与上述六个阶段混为一谈。事实上，process.nextTick的回调并不属于事件循环的任何一个阶段。它拥有自己独立的微任务队列，并且具有极高的执行优先级。每当一个阶段或同步代码执行完毕后，事件循环在进入下一个阶段之前，会优先清空process.nextTick队列中的所有回调。这种机制使得它非常适合用于在当前操作完成后、下一个I/O事件开始前，进行一些紧急的状态更新或错误处理。
与process.nextTick类似的还有基于Promise的微任务，例如Promise.then的回调。Promise微任务同样不属于事件循环的六个宏观阶段，而是作为微任务在每次宏任务执行完毕后被处理。然而，在Node.js的实现中，process.nextTick的优先级被设计为高于Promise微任务。这意味着如果两者同时存在，系统会先执行所有的nextTick回调，然后再执行Promise的then回调。理解这一细微差别，对于排查复杂的异步执行顺序问题具有重要意义。
// 演示微任务与宏任务的优先级差异
setTimeout(() => {
console.log('宏任务：timers阶段回调');
}, 0);
process.nextTick(() => {
console.log('微任务：nextTick回调，优先级最高');
});
Promise.resolve().then(() => {
console.log('微任务：Promise then回调，优先级次之');
});
综上所述，Node.js的事件循环通过精细的阶段划分与微任务队列的配合，实现了高效的异步非阻塞架构。在实际开发中，开发者应当根据任务的具体需求，合理选择setTimeout、setImmediate或微任务API。避免在process.nextTick中执行耗时操作或进行递归调用，以免导致事件循环被饿死，进而影响I/O回调的正常执行。掌握这些底层机制，将有助于我们编写出更加健壮、高效的Node.js服务端应用。