事件循环 | 流年石刻

好的，我们来彻底讲清楚 JavaScript 的事件循环（Event Loop）。这不仅仅是一个面试高频题，更是理解 JavaScript 异步编程、性能优化乃至整个语言运行机制的基石。

我会从“为什么需要它”这个第一性问题出发，逐步拆解它的组成部分、运行流程，并用实例来巩固理解。

1. 问题的根源：为什么 JavaScript 需要事件循环？

核心原因有两个：

JavaScript 是单线程的：这意味着在任意一个时间点，JavaScript 引擎只能执行一件任务。如果一个任务耗时很长（比如一个复杂的计算或者一个网络请求），那么后续的所有任务都必须排队等待，这会导致浏览器页面卡顿、失去响应，用户体验极差。
我们需要处理耗时操作：然而，现实世界充满了耗时操作，如网络请求（AJAX, Fetch）、用户的点击、鼠标移动、定时器（setTimeout）等。我们不能因为等待一个网络请求返回数据，就让整个页面冻结。

为了解决“单线程”与“耗时操作”之间的矛盾，JavaScript 的设计者引入了一套机制，使得它能够在不阻塞主线程的情况下，发起这些耗时任务，并在任务完成后回来处理结果。这套机制的核心，就是 事件循环 (Event Loop)。

一句话概括：事件循环是 JavaScript 用来协调各种事件、用户交互、脚本执行、UI 渲染和网络请求等任务的机制，它使得单线程的 JavaScript 能够实现非阻塞的并发效果。

2. 核心组成部分：事件循环的“玩家”们

想象一个高效的餐厅厨房，即使只有一个主厨（JS 主线程），也能有条不紊地处理大量订单。这个厨房需要几个关键的“角色”和“区域”：

调用栈 (Call Stack)：
- 作用：这是一个后进先出（LIFO）的数据结构，用来追踪哪个函数正在被执行。当一个函数被调用时，它会被推入（push）栈顶；当函数执行完毕返回时，它会被弹出（pop）。
- 类比：主厨当前正在处理的菜品清单。一次只能专心做一道菜。
Web APIs / Node.js APIs：
- 作用：这些不是 JavaScript 引擎的一部分，而是由运行环境（浏览器或 Node.js）提供的。像 setTimeout, DOM 事件, fetch() 这些异步操作，当在代码中被调用时，JavaScript 引擎会把它们移交给这些 API 去处理。
- 类比：厨房里的各种自动化设备，比如烤箱、咖啡机。主厨只需要设置好时间（调用 setTimeout），然后就可以离开去做别的菜，烤箱会在指定时间后“叮”一声。
任务队列 (Task Queue / Macrotask Queue)：
- 作用：这是一个先进先出（FIFO）的队列。当 Web API 完成了它的工作（比如定时器到期、网络请求成功），它不会直接把结果给 JavaScript 引擎，而是将准备好的回调函数（Callback Function）放入这个队列中排队。
- 类比：烤箱“叮”了之后，做好的菜被放在“待上菜”的传送带上，等待主厨有空来取。
微任务队列 (Microtask Queue)：
- 作用：这是另一个先进先出（FIFO）的队列，但它的优先级更高。专门用来存放特定类型的任务，最常见的就是 Promise 的 .then(), .catch(), .finally() 的回调，以及 async/await 中的 await 后面的代码。
- 类比：“加急/VIP”传送带。只要主厨一有空，他会优先处理这个传送带上的所有菜品，然后再去看普通的传送带。
事件循环 (Event Loop)：
- 作用：这是整个机制的“调度员”。它是一个持续运行的进程，不断地检查调用栈是否为空。
- 类比：厨房的经理。他不断地盯着主厨（调用栈），一旦发现主厨手头没事了（调用栈空了），他就会立刻去检查“VIP传送带”（微任务队列），把上面的所有东西都交给主厨。处理完所有VIP任务后，再从“普通传送带”（宏任务队列）上取一个任务交给主厨。

3. 运行流程：大循环如何运转

现在，我们将这些“玩家”串联起来，看看完整的流程：

同步代码执行：首先，整个 <script> 标签里的代码作为第一个宏任务 (Macrotask) 开始执行。同步代码会依次被压入调用栈并执行。

JavaScript
```
console.log('脚本开始'); // 1. 入栈，打印，出栈
```
遇到异步API：当遇到像 setTimeout, fetch 这样的异步 API 时，主线程不会等待它。它会将这个任务移交给对应的 Web API，并继续执行后面的同步代码。

JavaScript
```
setTimeout(function timeoutCallback() { // 2. 移交给 Web API 计时
    console.log('setTimeout 回调');
}, 1000);
```
同步代码执行完毕：主线程继续执行，直到所有同步代码执行完毕。

JavaScript
```
console.log('脚本结束'); // 3. 入栈，打印，出栈
```
此时，调用栈变为空。
事件循环开始工作：事件循环发现调用栈为空，开始检查任务队列。

微任务优先：事件循环会首先检查微任务队列。如果微任务队列中有任务，它会把队列中的所有微任务逐个取出，压入调用栈执行，直到微任务队列清空。

JavaScript

// 假设在之前的代码里有 Promise
Promise.resolve().then(function promiseCallback() {
    console.log('Promise 回调');
});
// 这个 promiseCallback 会在脚本结束后，立即被放入微任务队列，并优先于 setTimeout 执行

宏任务登场：当且仅当微任务队列被清空后，事件循环才会去宏任务队列中取一个任务，压入调用栈执行。
- 在这个例子中，1秒钟后，Web API 会将 timeoutCallback 函数放入宏任务队列。当事件循环处理完所有微任务后，就会来取这个 timeoutCallback 执行。
循环往复：执行完这个宏任务后，调用栈再次变空。事件循环会再次重复第 5 步：检查并清空所有微任务 -> 取一个宏任务执行 -> 检查并清空所有微任务 -> 取下一个宏任务... 这个过程不断重复，就形成了事件循环。

关键规则总结：

一次事件循环的周期，通常可以理解为：执行一个宏任务 -> 执行所有待处理的微任务 -> （可选）进行UI渲染 -> 准备下一个宏任务。

微任务拥有绝对的优先插队权。

4. 实例分析：让概念落地

这是一个经典的面试题，我们来用刚才的知识彻底拆解它。

JavaScript

console.log('1. 同步代码');

setTimeout(function() {
    console.log('2. setTimeout');
}, 0);

Promise.resolve().then(function() {
    console.log('3. Promise.then 1');
}).then(function() {
    console.log('4. Promise.then 2');
});

async function main() {
  console.log('5. async function start');
  await Promise.resolve(); // await 会让出线程
  console.log('6. async function end');
}
main();

console.log('7. 同步代码');

预测一下输出顺序，然后我们来分析：

逐步分析：

第一轮宏任务（主脚本执行）：
- console.log('1. 同步代码')：入栈执行，打印 1. 同步代码。
- setTimeout(...)：遇到 setTimeout，将其回调函数 () => console.log('2. setTimeout') 移交给 Web API 计时 (即使是0ms，也需要先移交再排队)。Web API 在大约0ms后，将该回调放入宏任务队列。
- Promise.resolve().then(...)：遇到 .then，将第一个回调 () => console.log('3. Promise.then 1') 放入微任务队列。
- main() 函数调用：
  - console.log('5. async function start')：入栈执行，打印 5. async function start。
  - await Promise.resolve(): await 是关键。它会暂停 async 函数的执行，并等待后面的 Promise 完成。重要的是，await 后面的代码 console.log('6. async function end') 会被包装成一个微任务，并放入微任务队列。然后，async 函数的执行权交还给主线程。
- console.log('7. 同步代码')：主线程继续执行，打印 7. 同步代码。
同步代码执行完毕，调用栈为空。 此时：
- 宏任务队列: [setTimeout的回调]
- 微任务队列: [Promise.then 1 的回调, async function end 的回调]
执行所有微任务：
- 事件循环检查微任务队列，发现不为空。
- 取出第一个微任务 () => console.log('3. Promise.then 1')，入栈执行，打印 3. Promise.then 1。这个 .then 执行后返回 undefined，但它后面链接了另一个 .then，所以 () => console.log('4. Promise.then 2') 这个新的回调被放入微任务队列的末尾。
- 此时微任务队列是：[async function end 的回调, Promise.then 2 的回调]。
- 继续执行微任务。取出 () => console.log('6. async function end')，入栈执行，打印 6. async function end。
- 继续执行微任务。取出 () => console.log('4. Promise.then 2')，入栈执行，打印 4. Promise.then 2。
- 微任务队列现在为空。
执行一个宏任务：
- 事件循环检查宏任务队列，发现不为空。
- 取出 setTimeout 的回调 () => console.log('2. setTimeout')，入栈执行，打印 2. setTimeout。
结束：
- 调用栈、微任务队列、宏任务队列都为空，脚本执行完毕。

最终的正确输出顺序：

1. 同步代码
2. async function start
3. 同步代码
4. Promise.then 1
5. async function end
6. Promise.then 2
7. setTimeout

总结与最佳实践

永远不要阻塞主线程：耗时长的计算应该考虑使用 Web Workers，I/O 操作（网络/文件）要使用异步 API。
理解 setTimeout(fn, 0)：它并不是立即执行，而是将 fn 放入宏任务队列的队首，等待下一个事件循环周期（即所有同步代码和所有现有微任务完成后）才执行。这常用于“让出”主线程，让浏览器有机会处理其他事情（如渲染）。
Promise 和 async/await 是微任务：它们的回调会比 setTimeout 等宏任务更早执行，这对于需要尽快响应的逻辑非常重要。
警惕微任务陷阱：如果一个微任务不断地向微任务队列中添加新的微任务（例如，在一个 .then 中再次调用一个立即 resolve 的 Promise.then），可能会导致宏任务（包括 UI 渲染和用户交互）永远得不到执行，造成页面假死。

彻底理解了事件循环，你就能准确预测代码的执行顺序，编写出更健壮、性能更好的 JavaScript 应用程序，并能自如地驾驭各种复杂的异步场景。

在 JavaScript 的异步模型中，事件循环（Event Loop）将任务分成了宏任务（Macrotask）和微任务（Microtask）。理解它们的区别，关键在于掌握它们在执行栈中的“优先级”和“触发时机”。

1. 常见的任务分类

宏任务 (Macrotasks)

宏任务是由宿主环境（浏览器或 Node.js）发起的任务。它们通常涉及比较复杂的操作，执行耗时相对较长。

script (整体代码)：第一遍解析的同步代码。
setTimeout / setInterval：定时器回调。
setImmediate (Node.js 独有)。
I/O 操作：网络请求完成、文件读写。
UI 渲染 (浏览器独有)：在宏任务执行完后的特定时机进行。

微任务 (Microtasks)

微任务是由 JavaScript 引擎自身发起的任务。它们的特点是“插队”执行，必须在当前宏任务结束之前清空。

Promise.then / catch / finally：Promise 的状态改变后的回调。
MutaionObserver：监听 DOM 变化的 API。
process.nextTick (Node.js 独有)：优先级最高的微任务。

2. 执行顺序（核心逻辑）

JavaScript 是单线程的，它像一个永不停歇的机器，按照以下逻辑循环：

执行一个宏任务（最初是整体 script 代码）。
清空微任务队列：宏任务执行完后，立即检查微任务队列。如果有任务，就依次执行，直到队列清空为止（如果在执行微任务期间又产生了新的微任务，也会在当前周期内执行完）。
渲染更新：如果需要，浏览器会进行 UI 渲染。
开始下一个宏任务：从任务队列中取出一个新的宏任务，重复上述步骤。

3. 为什么这样设计？

这种设计的本质是为了平衡“实时性”和“性能”。

宏任务适合处理那些不需要立即响应的大动作（如定时器）。
微任务则给了开发者一个在“当前任务执行完”和“下一个任务开始前”立即介入的机会。这对于需要保证逻辑连续性、更新状态而不触发不必要渲染的场景至关重要。

举个例子：

如果你在一个循环里不断产生宏任务（如 setTimeout），页面虽然会变慢，但不会卡死，因为浏览器有机会在宏任务之间插入渲染。

但如果你在循环里不断产生微任务（如递归调用 Promise.resolve().then(...)），页面会直接卡死，因为微任务队列永远清不空，浏览器没机会去处理渲染或用户交互。

4. 简单代码演练

你可以试着推导下面代码的输出顺序：

JavaScript

console.log('1');

setTimeout(() => {
    console.log('2');
}, 0);

Promise.resolve().then(() => {
    console.log('3');
});

console.log('4');

输出结果： 1 -> 4 -> 3 -> 2

1 & 4：同步执行（属于第一个宏任务）。
3：微任务，在第一个宏任务结束时立即执行。
2：第二个宏任务，排在下一轮循环。

如果你有具体的异步场景（比如复杂的 async/await 嵌套）需要拆解分析，我们可以深入探讨一下它的底层堆栈变化。

我会从“为什么需要它”这个第一性问题出发，逐步拆解它的组成部分、运行流程，并用实例来巩固理解。

1. 问题的根源：为什么 JavaScript 需要事件循环？

核心原因有两个：

JavaScript 是单线程的：这意味着在任意一个时间点，JavaScript 引擎只能执行一件任务。如果一个任务耗时很长（比如一个复杂的计算或者一个网络请求），那么后续的所有任务都必须排队等待，这会导致浏览器页面卡顿、失去响应，用户体验极差。
我们需要处理耗时操作：然而，现实世界充满了耗时操作，如网络请求（AJAX, Fetch）、用户的点击、鼠标移动、定时器（setTimeout）等。我们不能因为等待一个网络请求返回数据，就让整个页面冻结。

2. 核心组成部分：事件循环的“玩家”们

想象一个高效的餐厅厨房，即使只有一个主厨（JS 主线程），也能有条不紊地处理大量订单。这个厨房需要几个关键的“角色”和“区域”：

调用栈 (Call Stack)：
- 作用：这是一个后进先出（LIFO）的数据结构，用来追踪哪个函数正在被执行。当一个函数被调用时，它会被推入（push）栈顶；当函数执行完毕返回时，它会被弹出（pop）。
- 类比：主厨当前正在处理的菜品清单。一次只能专心做一道菜。
Web APIs / Node.js APIs：
- 作用：这些不是 JavaScript 引擎的一部分，而是由运行环境（浏览器或 Node.js）提供的。像 setTimeout, DOM 事件, fetch() 这些异步操作，当在代码中被调用时，JavaScript 引擎会把它们移交给这些 API 去处理。
- 类比：厨房里的各种自动化设备，比如烤箱、咖啡机。主厨只需要设置好时间（调用 setTimeout），然后就可以离开去做别的菜，烤箱会在指定时间后“叮”一声。
任务队列 (Task Queue / Macrotask Queue)：
- 作用：这是一个先进先出（FIFO）的队列。当 Web API 完成了它的工作（比如定时器到期、网络请求成功），它不会直接把结果给 JavaScript 引擎，而是将准备好的回调函数（Callback Function）放入这个队列中排队。
- 类比：烤箱“叮”了之后，做好的菜被放在“待上菜”的传送带上，等待主厨有空来取。
微任务队列 (Microtask Queue)：
- 作用：这是另一个先进先出（FIFO）的队列，但它的优先级更高。专门用来存放特定类型的任务，最常见的就是 Promise 的 .then(), .catch(), .finally() 的回调，以及 async/await 中的 await 后面的代码。
- 类比：“加急/VIP”传送带。只要主厨一有空，他会优先处理这个传送带上的所有菜品，然后再去看普通的传送带。
事件循环 (Event Loop)：
- 作用：这是整个机制的“调度员”。它是一个持续运行的进程，不断地检查调用栈是否为空。
- 类比：厨房的经理。他不断地盯着主厨（调用栈），一旦发现主厨手头没事了（调用栈空了），他就会立刻去检查“VIP传送带”（微任务队列），把上面的所有东西都交给主厨。处理完所有VIP任务后，再从“普通传送带”（宏任务队列）上取一个任务交给主厨。

3. 运行流程：大循环如何运转

现在，我们将这些“玩家”串联起来，看看完整的流程：

同步代码执行：首先，整个 <script> 标签里的代码作为第一个宏任务 (Macrotask) 开始执行。同步代码会依次被压入调用栈并执行。

JavaScript
```
console.log('脚本开始'); // 1. 入栈，打印，出栈
```
遇到异步API：当遇到像 setTimeout, fetch 这样的异步 API 时，主线程不会等待它。它会将这个任务移交给对应的 Web API，并继续执行后面的同步代码。

JavaScript
```
setTimeout(function timeoutCallback() { // 2. 移交给 Web API 计时
    console.log('setTimeout 回调');
}, 1000);
```
同步代码执行完毕：主线程继续执行，直到所有同步代码执行完毕。

JavaScript
```
console.log('脚本结束'); // 3. 入栈，打印，出栈
```
此时，调用栈变为空。
事件循环开始工作：事件循环发现调用栈为空，开始检查任务队列。

JavaScript

// 假设在之前的代码里有 Promise
Promise.resolve().then(function promiseCallback() {
    console.log('Promise 回调');
});
// 这个 promiseCallback 会在脚本结束后，立即被放入微任务队列，并优先于 setTimeout 执行

宏任务登场：当且仅当微任务队列被清空后，事件循环才会去宏任务队列中取一个任务，压入调用栈执行。
- 在这个例子中，1秒钟后，Web API 会将 timeoutCallback 函数放入宏任务队列。当事件循环处理完所有微任务后，就会来取这个 timeoutCallback 执行。
循环往复：执行完这个宏任务后，调用栈再次变空。事件循环会再次重复第 5 步：检查并清空所有微任务 -> 取一个宏任务执行 -> 检查并清空所有微任务 -> 取下一个宏任务... 这个过程不断重复，就形成了事件循环。

关键规则总结：

一次事件循环的周期，通常可以理解为：执行一个宏任务 -> 执行所有待处理的微任务 -> （可选）进行UI渲染 -> 准备下一个宏任务。

微任务拥有绝对的优先插队权。

4. 实例分析：让概念落地

这是一个经典的面试题，我们来用刚才的知识彻底拆解它。

JavaScript

console.log('1. 同步代码');

setTimeout(function() {
    console.log('2. setTimeout');
}, 0);

Promise.resolve().then(function() {
    console.log('3. Promise.then 1');
}).then(function() {
    console.log('4. Promise.then 2');
});

async function main() {
  console.log('5. async function start');
  await Promise.resolve(); // await 会让出线程
  console.log('6. async function end');
}
main();

console.log('7. 同步代码');

预测一下输出顺序，然后我们来分析：

逐步分析：

第一轮宏任务（主脚本执行）：
- console.log('1. 同步代码')：入栈执行，打印 1. 同步代码。
- setTimeout(...)：遇到 setTimeout，将其回调函数 () => console.log('2. setTimeout') 移交给 Web API 计时 (即使是0ms，也需要先移交再排队)。Web API 在大约0ms后，将该回调放入宏任务队列。
- Promise.resolve().then(...)：遇到 .then，将第一个回调 () => console.log('3. Promise.then 1') 放入微任务队列。
- main() 函数调用：
  - console.log('5. async function start')：入栈执行，打印 5. async function start。
  - await Promise.resolve(): await 是关键。它会暂停 async 函数的执行，并等待后面的 Promise 完成。重要的是，await 后面的代码 console.log('6. async function end') 会被包装成一个微任务，并放入微任务队列。然后，async 函数的执行权交还给主线程。
- console.log('7. 同步代码')：主线程继续执行，打印 7. 同步代码。
同步代码执行完毕，调用栈为空。 此时：
- 宏任务队列: [setTimeout的回调]
- 微任务队列: [Promise.then 1 的回调, async function end 的回调]
执行所有微任务：
- 事件循环检查微任务队列，发现不为空。
- 取出第一个微任务 () => console.log('3. Promise.then 1')，入栈执行，打印 3. Promise.then 1。这个 .then 执行后返回 undefined，但它后面链接了另一个 .then，所以 () => console.log('4. Promise.then 2') 这个新的回调被放入微任务队列的末尾。
- 此时微任务队列是：[async function end 的回调, Promise.then 2 的回调]。
- 继续执行微任务。取出 () => console.log('6. async function end')，入栈执行，打印 6. async function end。
- 继续执行微任务。取出 () => console.log('4. Promise.then 2')，入栈执行，打印 4. Promise.then 2。
- 微任务队列现在为空。
执行一个宏任务：
- 事件循环检查宏任务队列，发现不为空。
- 取出 setTimeout 的回调 () => console.log('2. setTimeout')，入栈执行，打印 2. setTimeout。
结束：
- 调用栈、微任务队列、宏任务队列都为空，脚本执行完毕。

最终的正确输出顺序：

1. 同步代码
2. async function start
3. 同步代码
4. Promise.then 1
5. async function end
6. Promise.then 2
7. setTimeout

总结与最佳实践

永远不要阻塞主线程：耗时长的计算应该考虑使用 Web Workers，I/O 操作（网络/文件）要使用异步 API。
理解 setTimeout(fn, 0)：它并不是立即执行，而是将 fn 放入宏任务队列的队首，等待下一个事件循环周期（即所有同步代码和所有现有微任务完成后）才执行。这常用于“让出”主线程，让浏览器有机会处理其他事情（如渲染）。
Promise 和 async/await 是微任务：它们的回调会比 setTimeout 等宏任务更早执行，这对于需要尽快响应的逻辑非常重要。
警惕微任务陷阱：如果一个微任务不断地向微任务队列中添加新的微任务（例如，在一个 .then 中再次调用一个立即 resolve 的 Promise.then），可能会导致宏任务（包括 UI 渲染和用户交互）永远得不到执行，造成页面假死。

彻底理解了事件循环，你就能准确预测代码的执行顺序，编写出更健壮、性能更好的 JavaScript 应用程序，并能自如地驾驭各种复杂的异步场景。

1. 常见的任务分类

宏任务 (Macrotasks)

宏任务是由宿主环境（浏览器或 Node.js）发起的任务。它们通常涉及比较复杂的操作，执行耗时相对较长。

script (整体代码)：第一遍解析的同步代码。
setTimeout / setInterval：定时器回调。
setImmediate (Node.js 独有)。
I/O 操作：网络请求完成、文件读写。
UI 渲染 (浏览器独有)：在宏任务执行完后的特定时机进行。

微任务 (Microtasks)

微任务是由 JavaScript 引擎自身发起的任务。它们的特点是“插队”执行，必须在当前宏任务结束之前清空。

Promise.then / catch / finally：Promise 的状态改变后的回调。
MutaionObserver：监听 DOM 变化的 API。
process.nextTick (Node.js 独有)：优先级最高的微任务。

2. 执行顺序（核心逻辑）

JavaScript 是单线程的，它像一个永不停歇的机器，按照以下逻辑循环：

执行一个宏任务（最初是整体 script 代码）。
清空微任务队列：宏任务执行完后，立即检查微任务队列。如果有任务，就依次执行，直到队列清空为止（如果在执行微任务期间又产生了新的微任务，也会在当前周期内执行完）。
渲染更新：如果需要，浏览器会进行 UI 渲染。
开始下一个宏任务：从任务队列中取出一个新的宏任务，重复上述步骤。

3. 为什么这样设计？

这种设计的本质是为了平衡“实时性”和“性能”。

宏任务适合处理那些不需要立即响应的大动作（如定时器）。
微任务则给了开发者一个在“当前任务执行完”和“下一个任务开始前”立即介入的机会。这对于需要保证逻辑连续性、更新状态而不触发不必要渲染的场景至关重要。

举个例子：

如果你在一个循环里不断产生宏任务（如 setTimeout），页面虽然会变慢，但不会卡死，因为浏览器有机会在宏任务之间插入渲染。

但如果你在循环里不断产生微任务（如递归调用 Promise.resolve().then(...)），页面会直接卡死，因为微任务队列永远清不空，浏览器没机会去处理渲染或用户交互。

4. 简单代码演练

你可以试着推导下面代码的输出顺序：

JavaScript

console.log('1');

setTimeout(() => {
    console.log('2');
}, 0);

Promise.resolve().then(() => {
    console.log('3');
});

console.log('4');

输出结果： 1 -> 4 -> 3 -> 2

1 & 4：同步执行（属于第一个宏任务）。
3：微任务，在第一个宏任务结束时立即执行。
2：第二个宏任务，排在下一轮循环。

如果你有具体的异步场景（比如复杂的 async/await 嵌套）需要拆解分析，我们可以深入探讨一下它的底层堆栈变化。