深入理解 Node.js 事件循环机制
先看一段代码，你能不假思索说出它的输出顺序吗：
console.log('1')
setTimeout(() => console.log('2'), 0)
Promise.resolve().then(() => console.log('3'))
process.nextTick(() => console.log('4'))
console.log('5')
答案是 1 5 4 3 2。如果你脱口而出的是 1 5 2 3 4，那这篇就是写给你的——setTimeout 写了 0 毫秒却排在最后，nextTick 后写却先跑，这背后就是事件循环在排队
我带新人的时候发现，大部分人对事件循环的理解停在「Node 是单线程、靠事件循环处理异步」这一句话。这句话没错，但它解释不了上面的输出，也解释不了线上为什么一个同步的 JSON.parse 大对象会把整个服务卡死。这篇就把这台「调度机器」拆开看一遍
事件循环不是 V8 给的，是 libuv 给的
很多人下意识以为事件循环是 JavaScript 引擎的一部分，其实不是。V8 只负责执行 JS、管理堆和调用栈，它根本不知道「定时器」「网络 IO」是什么
真正干调度活的是 libuv——一个 C 写的跨平台异步 IO 库，Node 把它当底座。你写的 fs.readFile、setTimeout、监听一个端口，最后都落到 libuv 手上。事件循环就是 libuv 里的一个主循环，它在不停地问一句话：「现在有哪些回调到点了，该执行谁？」
所以「Node 是单线程的」这句话要补全：执行你 JS 代码的是单线程，但底下的 IO 是 libuv 用线程池和操作系统的异步能力扛的。这个区分很关键，后面讲线程池会再回来。
六个阶段，循环往复
libuv 的事件循环每一轮（官方叫 tick）会依次走过六个阶段，每个阶段维护自己的一条回调队列。Node 官方文档 The Node.js Event Loop 给的顺序是这样的：
┌───────────────────────────┐
┌─>│ timers │ setTimeout / setInterval 的回调
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ pending callbacks │ 少数系统级回调,如某些 TCP 错误
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ idle, prepare │ Node 内部用,业务无感
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ poll │ ← 真正的重头戏:取 IO 事件、执行 IO 回调
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ check │ setImmediate 的回调
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
└──┤ close callbacks │ socket.on('close') 之类
└───────────────────────────┘
对业务开发真正要记住的是三个：timers、poll、check。其余三个要么是内部用的，要么只在很边缘的场景（比如 TCP 连接被拒）才碰到
- timers：检查有没有
setTimeout/setInterval到期。注意「到期」不等于「精确执行」——你写setTimeout(fn, 100),Node 只保证至少 100ms 后才可能执行，真正执行还得等循环转到这个阶段、且前面没人占着线程 - poll：整个循环的核心。它干两件事：计算该阻塞等待多久、然后执行 poll 队列里的 IO 回调（文件读完了、socket 来数据了）。如果队列空了，它会在这里停下来等新的 IO 事件，这就是一个空闲的 Node 进程不烧 CPU 的原因
- check：专门执行
setImmediate的回调。设计它就是为了给你一个「在 poll 之后、下一轮 timers 之前」插队的口子
真正的插队者：nextTick 与微任务
上面六个阶段是「宏观」队列。但还有两条优先级更高的队列，它们不属于任何一个阶段，而是在每个阶段切换的间隙都会被清空：
process.nextTick队列- 微任务队列(Promise 的
.then/.catch/.finally、queueMicrotask、await之后的代码)
执行规则是：当前这一步同步代码跑完，在进入下一个阶段之前，先把 nextTick 队列清空，再把微任务队列清空。两者都为空了，才允许事件循环往下走。而且 nextTick 优先级高于 Promise 微任务
现在回头看开头那段代码就通了：
console.log('1') // 同步,立即
setTimeout(() => console.log('2'), 0) // 进 timers 阶段队列
Promise.resolve().then(() => console.log('3')) // 进微任务队列
process.nextTick(() => console.log('4')) // 进 nextTick 队列
console.log('5') // 同步,立即
主模块同步代码先跑完 → 1、5。同步代码一结束，先清 nextTick → 4，再清微任务 → 3。这俩清空后，事件循环才正式开始转，转到 timers 阶段执行 setTimeout → 2。所以是 1 5 4 3 2
这里有个我踩过的坑要提醒：process.nextTick 听名字像是「下一轮 tick 再执行」，其实恰恰相反，它是在当前操作之后立刻执行，比任何 IO 都早。如果你写了一个会递归调用 process.nextTick 的逻辑，它会让事件循环永远进不到下一个阶段，IO 回调一个都跑不了，表现就是服务假死却不报错。我们线上真出过这种事，排查了大半天才定位到一个「看起来人畜无害」的递归 nextTick
一个补充的精确性说明：nextTick 优先于 Promise 微任务，这条规则在 CommonJS 和原生回调的检查点上成立。在 ESM 顶层这种「本身已经处于微任务上下文」的特殊场景里，顺序会有微妙差异。日常写业务记住「nextTick 比 Promise 早」就够了，真要抠这个边界，以你当前 Node 版本实测为准
那道经典面试题：setTimeout(fn,0) 和 setImmediate 谁先？
这是 Node 面试的钉子户，而且答案是「看情况」，这才是它有意思的地方
情况一：写在主模块里
setTimeout(() => console.log('timeout'), 0)
setImmediate(() => console.log('immediate'))
这段的输出不确定，可能 timeout 先，也可能 immediate 先。原因是 setTimeout(fn, 0) 实际会被钳到最小 1ms，而进程启动、跑到 timers 阶段要花多少时间是不确定的——如果准备耗时不足 1ms,timer 还没到期，这一轮 timers 阶段就空着过去了，先轮到 check 阶段的 setImmediate；反过来就是 timeout 先。这东西跟你机器当时的负载有关，所以别在生产里依赖它们俩的相对顺序
情况二：写在一个 IO 回调里
const fs = require('node:fs')
fs.readFile(__filename, () => {
setTimeout(() => console.log('timeout'), 0)
setImmediate(() => console.log('immediate'))
})
这段就稳定输出 immediate 先、timeout 后，百分百如此。因为这段代码本身就跑在 poll 阶段（IO 回调在这里执行），poll 之后紧接着就是 check 阶段，setImmediate 当轮就被执行；而 setTimeout 得等下一轮循环绕回 timers 阶段。「我想在当前 IO 处理完后，尽快再排一个回调」，正确答案是 setImmediate 而不是 setTimeout(fn, 0)，后者还要多等一整圈
别把事件循环和线程池搞混
讲到这必须澄清一个高频误解：不是所有异步都靠事件循环，有一部分靠 libuv 的线程池
libuv 维护一个默认 4 个线程的线程池(可通过环境变量 UV_THREADPOOL_SIZE 调整，上限 1024)，按 libuv 官方文档 的说法，它处理那些操作系统没有好的异步接口、或者纯 CPU 密集的活，主要是：
- 文件系统操作(
fs.*) - DNS 解析里的
dns.lookup(底层是getaddrinfo) crypto的一些操作(如pbkdf2、scrypt)zlib压缩
而网络 IO（TCP、UDP、HTTP）走的是另一条路——操作系统原生的事件通知机制(epoll / kqueue / IOCP)，不占线程池
这个区分有实际后果。线程池只有 4 个线程，意味着如果你同时发起 5 个耗时的文件读取或 pbkdf2，第 5 个必须排队等前面某个线程空出来。我见过一个服务在登录高峰期变慢，profiler 一看，瓶颈居然是密码哈希——pbkdf2 把 4 个线程占满了，后来的请求全在排队。解决就一行：启动前把 UV_THREADPOOL_SIZE 调大。但要注意，这个值必须在 Node 启动之前设好，进程跑起来再改无效
落到实处：不要阻塞事件循环
理解事件循环，最大的实战价值就一句话：执行你 JS 的是单线程，一旦你用一段长时间的同步代码占住它，整个服务的所有请求都得跟着卡
典型的「凶手」：
// 同步读大文件 —— 在这行读完之前,服务处理不了任何其他请求
const data = fs.readFileSync('./huge.json')
// 一个 O(n²) 的循环处理大数组
for (let i = 0; i < arr.length; i++)
for (let j = 0; j < arr.length; j++) {
/* ... */ }
// JSON.parse / JSON.stringify 一个几十 MB 的对象,也是同步阻塞
const obj = JSON.parse(hugeString)
这些都不是「慢」，而是「在它们跑的时候，事件循环根本转不动」，新进来的 HTTP 请求连被 accept 的机会都没有。判断一段代码会不会阻塞，标准很简单：它是不是同步的、且耗时随输入增长
应对思路：能异步就用异步版本(fs.promises.readFile 而不是 readFileSync)；真有 CPU 密集计算，挪到 worker_threads 或拆成小块分批处理，别让任何一段同步逻辑长时间霸占主线程。这部分官方专门有篇 Don't Block the Event Loop 值得一读
小结一张图
把脑子里的模型理顺，大概是这样：
- JS 执行是单线程，事件循环由 libuv 驱动，不是 V8
- 一轮循环依次过 timers → pending → idle/prepare → poll → check → close，业务上盯紧 timers / poll / check
- 每个阶段之间会清空 nextTick 队列和微任务队列，nextTick 比 Promise 微任务更早
- 在 IO 回调里想尽快再排一次，用
setImmediate；主模块里setTimeout(0)与setImmediate顺序不保证 - 文件 / DNS / crypto / zlib 走 4 线程的线程池，网络 IO 走操作系统事件机制
- 永远别用长同步代码堵住主线程
把这套模型装进脑子，你再看任何「异步顺序为什么是这样」的问题，基本都能自己推出来，而不用每次都跑一遍试
环境说明：本文示例在 Node.js 24（2026 年 6 月的 Active LTS）下验证。事件循环的阶段模型从 Node 早期就稳定至今，但 timers 与 poll 的某些细节在 libuv 1.45（Node 20 起）有过调整，跨大版本如遇顺序差异，以实测为准
参考来源
- The Node.js Event Loop（Node.js 官方）（六阶段、nextTick 与 setImmediate，采集于 2026-06-29）
- Don't Block the Event Loop（Node.js 官方）（阻塞主线程，采集于 2026-06-29）
- libuv — Thread pool work scheduling（线程池默认 4、上限 1024、覆盖 fs/dns/crypto/zlib，采集于 2026-06-29）
- Node.js — Releases（Node 24 为当前 Active LTS，采集于 2026-06-29）
