17370845950

JavaScript事件循环是协调同步代码、微任务和宏任务执行顺序的规则，非调度器；宏任务含setTimeout等，微任务含Promise.then等；每轮先执行一个宏任务，再清空所有微任务，最后渲染（浏览器）。

JavaScript 事件循环不是“调度器”或“线程管理器”，它是一套明确的执行规则，用来协调 同步代码、微任务（microtask） 和 宏任务（macrotask） 的执行顺序。理解它，关键不是背概念，而是看清楚代码里哪些操作会进哪个队列、谁先谁后。

宏任务和微任务分别包含哪些常见操作

混淆这两类任务是多数人卡壳的起点。它们不按“重要程度”分，而由宿主环境（浏览器或 Node.js）硬性规定：

• setTimeout、setInterval、setImmediate（Node.js）、I/O 回调、UI 渲染（浏览器）属于宏任务
• Promise.then/catch/finally、queueMicrotask、MutationObserver 回调属于微任务
• async/await 本质是 Promise 语法糖，所以 await 后面的代码会被包裹进微任务队列

事件循环每一轮到底做了什么

一次完整的事件循环迭代（也叫 tick），严格按以下三步走：

• 执行一个宏任务（例如从 setTimeout 回调中取一个）
• 执行**所有当前可执行的微任务**（注意：不是只执行一个，而是清空整个微任务队列）
• 渲染（仅浏览器环境，且有需要时）；然后进入下一轮，取下一个宏任务

这意味着，哪怕你连续写十个 Promise.resolve().then(...)，它们都会在同一个宏任务结束后**立刻、依次、无中断地执行完**，不会被中间插入的 setTimeout 打断。

立即学习“Java免费学习笔记（深入）”；

console.log(1);
setTimeout(() => console.log(2), 0);
Promise.resolve().then(() => console.log(3));
Promise.resolve().then(() => console.log(4));
console.log(5);
// 输出：1 → 5 → 3 → 4 → 2

为什么 await 后的代码看起来“延迟”了

await 不是暂停函数，而是把后续代码包装成微任务推入队列。它等的是 Promise 状态变更，但执行时机仍受微任务规则约束：

• 如果 await Promise.resolve()，后续代码会加入本轮微任务队列末尾，紧接在当前已排队的微任务之后
• 如果 await Promise.reject() 且没 catch，会触发 unhandledrejection，但该事件本身是微任务
• 不要误以为 await 等同于 setTimeout(..., 0) —— 前者进微任务，后者进宏任务，差整整一轮循环

Node.js 和浏览器在事件循环上的关键差异

Node.js 的事件循环有六个阶段（timers、pending callbacks、idle/prepare、poll、check、close callbacks），而浏览器没有显式阶段划分。最常踩的坑是：

• setImmediate 只存在于 Node.js，在浏览器中会报 ReferenceError
• Node.js 中 process.nextTick() 比所有微任务更优先（甚至在 Promise.then 之前执行），但它不属于标准事件循环规范，是 Node.js 特有机制
• 浏览器中没有 nextTick，但可用 queueMicrotask 达到类似效果

真正难的不是记住“微任务比宏任务快”，而是意识到：微任务队列会在每次宏任务结束时被**彻底清空**，哪怕新微任务是在已有微任务中动态注册的，也会在本轮内执行。这个细节决定了很多异步逻辑的实际走向，比如状态更新是否及时、错误是否被正确捕获。