事件循环决定异步代码执行时机：宏任务（如setTimeout）每轮执行一个，随后清空全部微任务（如Promise.then），故Promise回调总在setTimeout之前执行。
事件循环决定了哪些代码“看似同步”却实际异步执行
JavaScript 是单线程语言，但浏览器和 Node.js 都需要处理定时器、网络请求、用户交互等不阻塞主线程的任务。事件循环就是那个调度器——它不改变 call stack 的压栈弹栈规则，但决定什么时候把回调从任务队列（task queue 或 microtask queue）推入调用栈。
关键判断：如果你写了 setTimeout(() => console.log('a'), 0) 和 Promise.resolve().then(() => console.log('b'))，哪怕都“立即”安排，输出一定是 b 先于 a。这不是因为 Promise 更快，而是因为微任务（microtask）总在每次事件循环的宏任务（macrotask）结束后、渲染前清空。
宏任务 vs 微任务：两层队列的优先级差异
常见误区是认为“先到先执行”。实际上，事件循环有严格阶段：一次循环只执行一个宏任务（如 script 初始化、setTimeout 回调、setInterval 回调、I/O callback），但紧接着会**清空全部当前微任务队列**，再进入下一轮循环。
-
setTimeout、setInterval、setImmediate（Node.js）、I/O回调 → 宏任务 -
Promise.then/catch/finally、MutationObserver、queueMicrotask→ 微任务 -
requestAnimationFrame不属于这两类，它在渲染前触发，但不参与事件循环的“任务队列”调度
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出：1 → 4 → 3 → 2
为什么 await 后的代码不总在下一个宏任务里执行？
await 本身不直接产生宏任务或微任务，它只是语法糖，底层依赖 Promise。真正决定时机的是 await 等待的值是否为 Promise，以及该 Promise 的状态：
立即学习“Java免费学习笔记（深入）”；
- 如果
await 42（非 Promise），后续代码同步执行（同宏任务内） - 如果
await Promise.resolve(42)，后续代码被包装进Promise.then→ 进入微任务队列 - 如果
await new Promise(r => setTimeout(r, 0))，r()在下一轮宏任务中调用 → 后续代码在再下一轮微任务中执行
这解释了为什么 async function 内部的 await 后逻辑，看似“暂停”，实则被拆解成多个微任务片段，而非简单地“等完再继续”。
Node.js 和浏览器的事件循环实现有实质性区别
浏览器没有明确划分 poll、check、close callbacks 等阶段；而 Node.js 的 libuv 实现中，setImmediate 在 check 阶段执行，setTimeout(fn, 0) 在 timer 阶段执行——即使时间设为 0，它们也**不在同一阶段**，因此执行顺序可预测但不等价。
- 在 Node.js 中：
setTimeout(() => console.log('t'), 0)和setImmediate(() => console.log('i'))的输出顺序不确定（取决于进入事件循环时的阶段），但在 I/O 回调后紧接的调用中，setImmediate总是先于setTimeout - 浏览器中无
setImmediate，应统一用queueMicrotask或Promise.resolve().then替代微任务需求
最易忽略的一点：事件循环本身不“执行”代码，它只是协调机制；真正的执行始终发生在调用栈中。任何对“异步变同步”的尝试（比如用 while(Date.now() 模拟 sleep）都会卡死整个线程，让所有任务（包括渲染、响应点击）停滞——这不是事件循环失效，而是你绕过了它。
