1. 事件循环到底在解决什么问题
1.1 单线程的尴尬：一次只能干一件事
我最早被事件循环折磨，是在一次线上问题排查中。当时Node服务偶尔会出现“某个定时任务比预期晚了近一秒钟执行”，日志和业务逻辑怎么查都没问题，后来才反应过来：不是定时器不准，是事件循环被前面的同步任务堵住了。JS和Node都是单线程的，这意味着同一时刻只有一条执行主线在跑。你看浏览器里可以同时渲染页面、响应点击、接收网络数据，实际上这些都是幕后线程先干完活，再通过事件循环把结果“喂”给JS主线程。单线程的优势是省心，不用像多线程一样考虑加锁、死锁；劣势也彻底暴露：主线程一旦被某个大任务占住，后面所有事情都得排队。事件循环就是这套“排队叫号”规则的总称，它决定了你写的每一段异步回调到底什么时候被执行。
这里我再用一个特别接地气的例子说明：想象一个食堂窗口只有一个打饭阿姨，她不可能一边给A同学打饭，一边给B同学打饭。她的做法是：同步任务就是她手里的动作，一边打饭一边嘴上叫号；遇到需要厨房加菜的（相当于异步I/O），她就先让厨房去准备，自己继续打下一份；等加菜好了，她把对应同学的回调排到后面，按顺序叫。事件循环就是那个“排队叫号系统”，而宏任务、微任务、nextTick这些，是叫号规则里的优先级插队机制。
1.2 为什么叫“循环”而不叫“队列”
很多人初学时有个误区，以为异步任务按顺序进一个队列，从头到尾执行一次就结束了。真正的事件循环是一个无限循环，每转一圈做固定几件事：取一个宏任务执行，执行完清空所有微任务，然后继续取下一个宏任务。浏览器里可能还要在这中间渲染页面。因为是循环，所以任何时刻新产生的异步任务，都会在后续某轮中被处理。这也意味着，某一轮执行时间过长，下一轮就会被拖慢，这是后面所有坑的总根源。
1.3 这个知识到底能解决什么问题 / 适合谁看
事件循环不是纯面试考点，它直接影响你写高性能Node服务、排查线上Bug、深挖框架源码的能力。比如面试必聊的“Promise为什么比setTimeout先执行”、Node面试题常问的“setImmediate和setTimeout谁先跑”，本质都是事件循环。再比如你在Vue/React项目里看到nextTick、在Express中间件里看到异步执行顺序，底层也都能映射回这套机制。这篇文章适合前端、后端Node开发者，以及正在准备面试的同学阅读，读的时候最好开一个终端跟着写代码验证。
2. 浏览器里的事件循环：宏任务与微任务
2.1 三个关键角色
浏览器里的事件循环，核心就三个东西：执行栈、宏任务队列、微任务队列。
- 执行栈（Call Stack）：当前正在执行的同步代码组成的调用栈。栈顶是正在运行的函数，栈底是入口。
- 宏任务队列（Macrotask Queue）：也叫任务队列，放的是setTimeout、setInterval、I/O、事件回调等“大头任务”。
- 微任务队列（Microtask Queue）：放的是Promise.then/catch/finally、queueMicrotask、MutationObserver等“小任务”。
浏览器的规则是：同步代码执行完（执行栈为空）后，先把微任务队列里所有任务一次性清空，然后再去宏任务队列取下一项执行。注意“所有”两个字，微任务执行过程中如果又产生了新的微任务，也会在当前轮被处理掉，不会拖到下一轮。这就是大家常说的“微任务插队”。
2.2 经典面试题逐行走读
很多同学背过这道题，但不知道内部发生了什么：
console.log('1'); setTimeout(() => { console.log('2'); }, 0); Promise.resolve().then(() => { console.log('3'); }); console.log('4');输出是1 4 3 2。我带着你从头走一遍：
- 同步执行
console.log('1')，输出1。 - 遇到
setTimeout(fn, 0)，JS把定时器交给浏览器底层计时，0毫秒后回调会被投放到宏任务队列。注意，就算写0，也不会立刻执行，因为要等同步代码先跑完。 - 遇到
Promise.resolve().then(fn)，回调立刻被丢进微任务队列。 - 执行
console.log('4')，输出4。 - 执行栈空了，浏览器先清空微任务队列，输出3。
- 最后从宏任务队列取出setTimeout回调，输出2。
这道题背后的原理就是“先同步，再微任务，最后宏任务”。理解了这一层，下面再进阶就顺了。
2.3 async/await 在事件循环里的真实身份
async/await本质上是Promise的语法糖。sleep(1000)这种写法不是让主线程真的“停下来睡”，而是把await后面的代码暂时挂起，等Promise决裂后再放进微任务队列。这一点很多人会想歪，我举一个典型的例子：
async function test() { console.log('A'); await Promise.resolve(); console.log('B'); } test(); console.log('C');输出顺序是A C B。因为test函数同步执行到await这一行，然后立刻让出线程，console.log('B')相当于被塞进then回调里，成了微任务。主线程接着执行console.log('C')。等同步代码清空后，微任务队列里的B才被执行。
如果你在await后面又放多层await，那么它们会形成Promise链，一层层进入微任务队列，顺序依然保持“先进先出”的相对次序。实际排查异步Bug时，画一个简单的“同步/微任务/宏任务”三层时间轴，很多问题一眼就能看出来。
2.4 渲染时机：别再用死循环恶心浏览器
浏览器的事件循环还有一个重要职责：渲染页面。它是这样安排的：每执行完一个宏任务，浏览器在清空微任务队列之后，根据是否需要来决定是否渲染一帧。所以，如果主线程被一个while(true)死循环占着，渲染永远得不到机会，页面就卡死了。这也是为什么requestAnimationFrame不按宏任务/微任务来算，它专门挂在渲染流程里，由浏览器在合成帧之前触发。平时写动画、写重逻辑，尽量不要把长时间同步任务堆在主线程上，这是对事件循环最基本的尊重。
3. Node.js的事件循环：六个阶段怎么轮转
3.1 六个阶段都在干嘛
Node.js的事件循环不是简单的“宏任务队列”模型，而是一个六个阶段串起来的轮转机制。每个阶段都有自己的回调队列，一次循环依次经过这些阶段。顺序如下：
- timers：执行setTimeout、setInterval到期的回调。注意“到期”不是“到点执行”，到点了只是把回调塞进这个阶段的队列，如果上一轮循环还在跑，它就得等。
- pending callbacks：处理一些系统级回调，比如某些底层I/O的错误回调、连接断开等。一般业务代码不太直接操作这里。
- idle, prepare：这是libuv内部使用的阶段，和业务无关，你可以把它理解为系统内部检查和准备工作的“后台时间”。
- poll：这个阶段最关键。它会计算剩余的阻塞时间，如果有新I/O事件（比如TCP连接、文件读写完成）就处理；如果没有任务，会在这里等待事件到来。它也是绝大多数异步回调被真正执行的地方。
- check：执行setImmediate()的回调。setImmediate直接命名了“立即执行”，但在Node里它并非真的立刻，而是要等当前poll阶段结束后，在这个check阶段执行。
- close callbacks：处理socket或句柄关闭时的close事件，比如
stream.on('close')。
一个容易混淆的点：网络I/O回调到底在哪执行？实际大多在poll阶段，也有一些系统事件在pending callbacks阶段。初学者别抠“哪个回调精确归哪个阶段”的细节，先把握整体转轮：轮完一圈再转下一圈。
3.2 阶段之间的“插队者”：process.nextTick与微任务
除了六个阶段，Node还有一个大杀器：process.nextTick。它不在任何阶段里，而是在“进入下一个阶段之前”和“当前阶段最后一个回调执行完之后”检查并执行。底层上，process.nextTick回调被存储在一个专门的nextTickQueue里，每次阶段切换时都会把队列清空。换句话说，它比Promise微任务还要“插队”。
Node的Promise微任务处理时机呢？在Node 11版本之后，行为发生了重要调整：每个阶段内部的每个回调执行完后，都会检查并执行一遍微任务队列。这个调整让浏览器和Node的微任务行为更一致了，也导致很多老教程里的结论失效。我建议在Node 14以上版本跑测试，别再看网上那些基于旧版写的老答案。
3.3 setImmediate 和 setTimeout(0)：为什么谁先跑不一定
这是Node事件循环里最经典的面试题。分两种情况：
第一种，在main模块（也就是脚本顶层）里同时调用：
setTimeout(() => console.log('timeout'), 0); setImmediate(() => console.log('immediate'));输出顺序不确定。原因是脚本启动后进入事件循环，到timers阶段时，setTimeout已经到期（因为启动消耗的时间可能已经超过0ms），于是先执行timeout，然后在check阶段执行immediate；但如果机器启动进程耗时较长，setTimeout的回调在进入timers阶段时可能已经就绪，这两种时机谁能抢先，取决于运行环境。实测多次，结果可能来回变。
第二种，在I/O回调里同时调用：
const fs = require('fs'); fs.readFile(__filename, () => { setTimeout(() => console.log('timeout'), 0); setImmediate(() => console.log('immediate')); });这里setImmediate在setTimeout前面执行。因为readFile回调在poll阶段执行，执行完当前阶段后，下一个阶段就是check，setImmediate立刻执行；而setTimeout要等到下一轮循环的timers阶段。理解了这个阶段顺序，你才知道“谁先谁后”不是背出来的，是推算出来的。
3.4 Node与浏览器事件循环的差异对照
很多前端同学在浏览器里理解了宏任务/微任务，到了Node却看不懂文档，因为两套模型不完全一样。我整理一个对照表：
| 对比项 | 浏览器 | Node.js |
|---|---|---|
| 宏任务组织方式 | 一个宏任务队列 | 六个阶段，每个阶段一个队列 |
| 微任务清空时机 | 每个宏任务执行完后清空 | 每次阶段切换时检查，旧版更宽松 |
| setImmediate | 不支持 | 支持，在check阶段执行 |
| process.nextTick | 不支持 | 阶段间插队，优先级最高 |
| 渲染 | 宏任务后可能渲染 | 无渲染机制 |
| 定时器 | setTimeout宏任务 | timers阶段处理 |
还有一个常见混淆点：Vue/React里的nextTick是框架自己实现的排队机制，和Node的process.nextTick只是同名，不要再把两者混为一谈。你查异步问题时，先确认你运行在浏览器还是Node环境，再套对应模型。
4. 实操：写代码验证事件循环
4.1 环境准备：用nvm安装Node并配置npm源
验证事件循环不需要特别环境，一个Node和一个浏览器Console就够了。但很多新人卡在第一步：Node装不上，或者装完npm不能用。我建议用nvm来管理Node版本，它能在同一台机器上装多个Node版本，方便以后切换。安装nvm以后，执行：
nvm install --lts nvm use --lts node -v npm -v如果你发现npm命令报错，多半是安装路径没纳入PATH，或者是旧版本残留。Windows上有时候需要关闭终端重开，或者检查用户目录下的.nvm配置。装好后如果下载npm包太慢，可以配置国内源：
npm config set registry https://registry.npmmirror.com这一步是为了下载依赖包更快、更稳，不影响任何语言机制。至于“Node高版本兼容低版本吗”，多数场景下新版Node能跑旧版代码，但一些老旧原生模块（比如早期node-sass这类）可能编译不过，所以遇到老项目时用nvm切换版本就好。
4.2 在浏览器Console里验证宏任务/微任务
打开Chrome的开发者工具Console，粘贴下面这段代码：
console.log('start'); setTimeout(() => console.log('timeout'), 0); Promise.resolve().then(() => console.log('promise1')); Promise.resolve().then(() => console.log('promise2')); console.log('end');预期输出顺序是：
start end promise1 promise2 timeout我实测多次，顺序稳定。这里的promise1和promise2会按照.then注册顺序执行，而且都在timeout前。这验证了“微任务优先于宏任务”。如果你把第二个.then里的内容改成发起一个新的微任务，比如：
Promise.resolve().then(() => { console.log('p1'); Promise.resolve().then(() => console.log('p2')); }); setTimeout(() => console.log('timeout'), 0);输出是p1 p2 timeout。这说明当前轮清空微任务队列时，会把新产生的微任务也一并处理掉，不会拖延到下一轮。
4.3 在Node里验证六个阶段和插队机制
写一个脚本，在I/O回调里同时触发nextTick、Promise、setImmediate和setTimeout：
const fs = require('fs'); fs.readFile(__filename, () => { process.nextTick(() => console.log('nextTick')); Promise.resolve().then(() => console.log('promise')); setImmediate(() => console.log('setImmediate')); setTimeout(() => console.log('setTimeout'), 0); }); console.log('main start');我在Node 18下实测，输出顺序是：
main start nextTick promise setImmediate setTimeout这里有个细节：fs.readFile回调在poll阶段，执行完后，Node会先处理该阶段里产生的nextTick队列，再处理Promise微任务队列，然后进入check阶段执行setImmediate。setTimeout要下一轮才到timers阶段，所以排在最后。这就把理论落到了实处。
4.4 验证“main模块里setTimeout和setImmediate其实没准儿”
为了打破“setTimeout一定先执行”的直觉，多跑几次下面这个脚本：
node -e "setTimeout(() => console.log('timeout'), 0); setImmediate(() => console.log('immediate'));"多跑几次，你会发现输出可能在timeout immediate和immediate timeout之间变化。这正是因为timers阶段启动前，0ms定时器是否已经就绪受到系统调度影响。不用怀疑自己写错，这是正常现象，也是理解“事件循环有阶段，不是简单队列”的最好验证。
5. 常见问题与排查技巧实录
5.1 setTimeout为什么不准时
很多人在业务里用setTimeout做延迟提醒，结果发现比预期晚了几百毫秒甚至更多。这不是Node的锅，而是事件循环的重要特性：setTimeout只是“到时间后把回调排入队列”，不是“到时间后立刻执行”。如果前面有同步长任务或密集微任务，它只能排队等着。
排查方法也很简单：在疑似卡顿的位置前后各打一个console.log(Date.now())或performance.now()，看两段耗时。如果你发现长耗时出现在主线程上，就该考虑把任务拆成小块，或者交给worker_threads。事件循环不是不让你干活，而是要求你干完一块、交还控制权，再干下一块。
5.2 CPU密集任务把事件循环堵死了
典型错误写法：在一次HTTP请求里做超大数组排序或复杂计算。这时候Node服务会“假死”，其他请求全部排队，定时器也全部迟到。因为事件循环只有一个主线程在跑这些计算。
解法有三个层次：
- 第一层：分解任务。比如把大排序拆成多块，每块之后用
setImmediate(() => 继续下一块)交还控制权。 - 第二层：用
worker_threads或者child_process把计算丢到独立线程/进程，主线程只负责调度。 - 第三层：进程守护。如果服务已经因为各种原因崩溃，用PM2这类工具托管进程，它能在进程退出后自动拉起。很多新手习惯于登录服务器跑
node app.js，一断开连接服务也停了，这也是热词里“通过ssh连接服务器断开以后node服务会停”的常见原因，用PM2以后台守护方式运行就能解决。
注意：这里说的“堵死”不是进程退出，而是事件循环空转不出来。脑内图景就是把食堂打饭阿姨给围住了，她没法抽身去叫下一个号。
5.3 nextTick递归会导致I/O饥饿
process.nextTick虽然方便，但用起来要克制。看下面这个例子：
function loop() { process.nextTick(loop); } loop();这个递归会不断往nextTickQueue里塞任务，而事件循环每次进入新阶段前都要先把这队列清空，导致其他I/O、定时器永远得不到执行机会。这就是“I/O饥饿”。如果你确实要做异步递归，建议用setImmediate，因为它在check阶段才执行，至少不会抢占阶段切换的调度权。
5.4 如何用事件循环思维定位异步Bug
我遇到过最典型的场景：一个Node接口里同时发了多条SQL查询，然后在一个Promise.all里汇总返回，结果发现其中某个子查询的结果偶尔不是最新的。仔细排查后发现，是有人在一个微任务里提前改了查询参数，导致后面真正执行SQL时用的是新值。这种Bug靠打印日志都很难找，但如果你把执行顺序套上“同步、微任务、宏任务”的三层模型，一眼就能看出：修改参数那步虽然是同步代码，但它所在的Promise回调是微任务，而SQL执行回调是I/O宏任务，微任务必然先执行。定位的通用方法就是：在关键代码前后打日志，然后把日志顺序画成时间轴，再对照事件循环规则分析，没有玄学。
5.5 面试高频题怎么答
结合当下的面试热度，我把几个高频问题浓缩成一句话版本：
- 为什么Promise比setTimeout先执行？Promise回调是微任务，setTimeout回调是宏任务，每执行完一个宏任务要先把微任务清空，所以微任务总是先执行。
- setImmediate和setTimeout谁先？在I/O回调里setImmediate先，因为poll阶段之后是check阶段；在main模块里不确定，看两个阶段的竞争时机。
- async/await和事件循环有什么关系？await把后续代码变成Promise续体，按微任务调度。
- process.nextTick和setImmediate有什么区别？nextTick在阶段切换前优先执行，setImmediate只在check阶段执行，前者的优先级更高，滥用会导致I/O饿死。
另外，面试官如果提“js 事件中的 event”，记得先澄清：DOM事件对象和事件循环是两个概念。前者是用户交互产生的Event对象，后者是异步任务调度机制。二者的共同点是都依赖队列，但千万别混在一起答。
我在实际项目中绕了很多弯路，最后才形成一套习惯：凡是涉及异步顺序的地方，先写一小段“同步/微任务/宏任务”的标注；凡是启动Node服务，都用PM2托管起来，避免意外断连导致服务沉默；凡是看到process.nextTick，第一反应是检查有没有递归风险。事件循环这个知识点，背答案容易，真正融入自己的排查思维需要亲手跑一批小脚本。如果你看完这篇文章，能自己写出那三个验证脚本，并且跑完解释清楚顺序，那我敢说你以后再遇到异步怪问题，会比大多数人冷静得多。
