事件循环决定异步代码执行时机：宏任务（如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 的状态：

• 如果 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）都会卡死整个线程，让所有任务（包括渲染、响应点击）停滞——这不是事件循环失效，而是你绕过了它。