事件循环(Event Loop)完整解析

事件循环（Event Loop）是 JavaScript 运行时协调同步代码、异步回调和任务队列的一套机制。JavaScript 主线程一次只执行一个调用栈，但浏览器或 Node.js 会把定时器、网络请求等异步结果放入任务队列，等调用栈空闲后再取出执行。面试时要重点说清楚：同步代码先执行；当前任务结束后清空微任务；然后才有机会执行下一个宏任务，并在浏览器中安排渲染。

> JavaScript 只有一位主厨，但订单可以先排队。事件循环负责安排这些订单：先做当前锅里的，再处理微任务，最后取下一张宏任务。 ## 目录 - [一、先建立直觉：JavaScript 为什么能处理异步](#一先建立直觉javascript-为什么能处理异步) - [二、调用栈：同步代码怎么执行](#二调用栈同步代码怎么执行) - [三、宏任务和微任务](#三宏任务和微任务) - [四、事件循环的完整流程](#四事件循环的完整流程) - [五、用一段代码追踪执行顺序](#五用一段代码追踪执行顺序) - [六、边界问题：看起来是异步，实际可能排长队](#六边界问题看起来是异步实际可能排长队) - [七、浏览器和 Node.js 的差异](#七浏览器和-nodejs-的差异) - [八、总结](#八总结) ## 一、先建立直觉：JavaScript 为什么能处理异步 JavaScript 主线程通常一次只能执行一段 JavaScript 代码。它不是同时炒十口锅，而是把暂时做不了的工作交给运行环境： - 调用栈负责执行当前的同步代码。 - 浏览器或 Node.js 负责计时器、网络、文件和用户事件等环境能力。 - 任务队列负责保存已经可以继续执行的回调。 - 事件循环负责在合适的时机，把队列中的回调放回调用栈。 这里的“异步”不等于 JavaScript 主线程同时执行多段代码。更准确的说法是：耗时工作由运行环境处理，JavaScript 在结果准备好后再执行回调。 ## 二、调用栈：同步代码怎么执行 调用栈（Call Stack）遵循后进先出（LIFO，Last In First Out）。最后进入栈的函数，会最先执行完并离开： ```javascript function first() {   second(); } function second() {   third(); } function third() {   console.log('third'); } first(); ``` 执行 `first()` 时，调用栈大致经历： | 时刻 | 栈顶到栈底 | 动作 | | --- | --- | --- | | 1 | `first` | 进入 `first` | | 2 | `second → first` | `first` 调用 `second` | | 3 | `third → second → first` | `second` 调用 `third` | | 4 | `second → first` | `third` 执行完毕 | | 5 | `first` | `second` 执行完毕 | | 6 | 空 | `first` 执行完毕 | 同步代码没有执行完之前，事件循环不会插队执行定时器或 Promise 回调。同步代码写得太重，页面就会出现“按钮点了但没反应”的感觉。 ## 三、宏任务和微任务 ### 1. 宏任务是什么 宏任务（Macrotask）可以理解为一次较完整的工作单元。常见来源包括： - 整段脚本的初始执行。 - `setTimeout` 和 `setInterval` 回调。 - 用户点击、键盘输入等事件回调。 - 网络、文件等 I/O 回调（具体由运行环境安排）。 - `MessageChannel` 等消息任务。 “宏任务”是开发者常用的称呼。浏览器规范更常使用 task（任务）和不同的任务源，不同任务源的调度细节不应简单理解成一条绝对固定的队列。 ### 2. 微任务是什么 微任务（Microtask）比下一个宏任务更急。常见来源包括： - `Promise.then`、`Promise.catch`、`Promise.finally` 回调。 - `queueMicrotask` 回调。 - 浏览器中的 `MutationObserver` 回调。 当前宏任务执行结束后，事件循环会不断取出微任务，直到微任务队列变空。微任务执行期间产生的新微任务，也会在本轮继续执行。 可以用一句话记忆：**同步代码先跑完，微任务清空后，才轮到下一个宏任务。** ### 3. `setTimeout(fn, 0)` 不是立刻执行 `0` 只表示不主动增加明显延迟，并不表示马上把回调塞进调用栈。它至少要等待： 1. 当前同步代码执行结束。 2. 当前任务产生的微任务全部执行结束。 3. 浏览器或 Node.js 选择到达这个定时器任务的时机。 因此，`setTimeout` 更像“有空时叫我”，不是“现在立刻叫我”。 ## 四、事件循环的完整流程 以浏览器中的普通脚本为例，一轮事件循环可以简化成下面的流程： 1. 从任务队列中取出一个任务，例如执行整段脚本或一个点击回调。 2. 执行这个任务里的同步代码，直到调用栈清空。 3. 清空微任务队列；微任务产生的新微任务也要继续处理。 4. 浏览器在合适的时机进行布局、绘制和合成，具体是否渲染由浏览器决定。 5. 再取下一个任务，重复上面的流程。 可以把它想成餐厅叫号：当前号码必须先服务完；后厨加急的小票（微任务）要先处理；窗口空下来后，才叫下一个普通号码（宏任务）。 ## 五、用一段代码追踪执行顺序 先看最小案例。为了先看懂主线，这里不加入网络请求和渲染细节： ```javascript console.log('同步 1'); setTimeout(() => {   console.log('宏任务：setTimeout'); }, 0); Promise.resolve().then(() => {   console.log('微任务：Promise.then'); }); queueMicrotask(() => {   console.log('微任务：queueMicrotask'); }); console.log('同步 2'); ``` 预期输出是： ```text 同步 1 同步 2 微任务：Promise.then 微任务：queueMicrotask 宏任务：setTimeout ``` ### 拆解这段代码 1. 脚本本身是当前任务，先执行两条同步日志，所以 `同步 1` 和 `同步 2` 最先出现。 2. `setTimeout` 注册计时器，回调暂时不会进入调用栈。 3. `Promise.resolve().then(...)` 和 `queueMicrotask(...)` 依次进入微任务队列。 4. 当前脚本结束后，事件循环按先进先出的顺序处理两个微任务。 5. 微任务队列清空后，才有机会执行 `setTimeout` 回调。 再看 `async/await`： ```javascript async function loadData() {   console.log('async 开始');   await Promise.resolve();   console.log('await 之后'); } console.log('脚本开始'); loadData(); console.log('脚本结束'); ``` 输出顺序是： ```text 脚本开始 async 开始 脚本结束 await 之后 ``` `await` 之前的代码仍然是同步执行；`await` 之后的部分可以理解为注册了一个 Promise continuation（继续执行的微任务）。 ## 六、边界问题：看起来是异步，实际可能排长队 ### 1. 微任务太多会阻塞渲染和宏任务 问题代码： ```javascript function keepBusy() {   queueMicrotask(keepBusy); } keepBusy(); ``` 这个循环不断往微任务队列追加新任务。由于事件循环必须先把微任务清空，`setTimeout`、用户点击和浏览器渲染都可能迟迟得不到机会。 修复思路是把长任务拆开，让出执行机会。例如批量处理数据时，每处理一批就使用 `setTimeout`、`MessageChannel` 或 `requestAnimationFrame` 把后续工作交还给下一轮任务。不要用无限微任务循环“霸占柜台”。 ### 2. 任务顺序不等于代码书写顺序 ```javascript setTimeout(() => console.log('timer 1'), 0); Promise.resolve().then(() => {   console.log('promise 1');   setTimeout(() => console.log('timer 2'), 0); }); console.log('sync'); ``` 输出通常是： ```text sync promise 1 timer 1 timer 2 ``` 原因是 `timer 1` 已经先进入定时器任务队列；微任务执行时才注册 `timer 2`，所以它排在后面。这里讨论的是常见浏览器行为，跨环境时仍应以目标运行时测试为准。 ### 3. `forEach` 不会等待异步回调 ```javascript items.forEach(async (item) => {   await save(item); }); console.log('可能提前打印'); ``` `forEach` 不会收集并等待这些 Promise。需要顺序执行时使用 `for...of`；需要并发等待全部完成时使用 `Promise.all`： ```javascript await Promise.all(items.map((item) => save(item))); ``` 这不是事件循环“失灵”，而是调用方没有把异步结果接回当前流程。 ## 七、浏览器和 Node.js 的差异 浏览器和 Node.js 都有事件循环，但实现细节不同： - 浏览器会把渲染机会安排在任务和微任务之间的合适位置。 - Node.js 的事件循环分为多个阶段，例如定时器、I/O 回调、`setImmediate` 等。 - Node.js 的 `process.nextTick` 有自己的优先级，通常会在普通 Promise 微任务之前处理；大量使用同样可能造成饥饿。 - 不要只凭浏览器控制台里的输出，推断所有 Node.js 版本和场景的顺序。 面试回答原理时可以先说浏览器的通用模型；如果面试官追问 Node.js，再补充“阶段”和 `process.nextTick` 的差异。 ## 八、总结 - JavaScript 主线程一次执行一个调用栈，异步能力由运行环境协助完成。 - 当前同步任务结束后，事件循环会先清空微任务，再处理下一个宏任务。 - `Promise.then`、`queueMicrotask` 属于微任务；`setTimeout` 和用户事件通常属于宏任务。 - `setTimeout(fn, 0)` 不是立即执行，至少要等当前代码和微任务完成。 - 无限微任务会阻塞渲染和后续任务；长任务要拆分并主动让出执行机会。 - 浏览器和 Node.js 都遵循事件循环思想，但任务阶段和优先级存在差异。 ## 九、问题 为啥要把异步任务放入到队列中，而不是一个调用栈中执行所有的同步代码和异步代码 ```javascript // 假设这是“同一个调用栈”的执行方式（伪代码） console.log('开始'); setTimeout(() => console.log('延迟'), 1000); // 假设这里卡住1秒 console.log('结束'); ``` 如果调用栈直接执行 setTimeout，CPU 就会在这个栈帧里死等 1 秒（因为栈帧没销毁，后续代码进不来）。这 1 秒内，页面无法点击、无法滚动、动画卡死，这就是阻塞。 调用栈的规矩是：不执行完当前函数，绝不执行下一个。 异步任务（尤其是 I/O、定时器、网络请求）的耗时是不可控的（可能是 1ms，也可能是 10 秒），如果把不可控的等待塞进调用栈，就等于把页面的命脉交给了网络延迟。