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