事件循环按任务类型和轮次调度：每执行完一个宏任务，立即清空全部微任务，再执行下一个宏任务；微任务可链式触发并持续执行至队列为空，宏任务则严格排队至下一轮。
事件循环不是“等空闲再执行”，而是同步代码一退场，微任务立刻顶上，宏任务排在后面等下一轮。它不靠时间先后排序，而靠任务类型和调度规则决定谁先跑。
宏任务和微任务：优先级不是“快慢”，是“轮次”
宏任务（setTimeout、setInterval、script 整体、I/O、UI 渲染）和微任务（Promise.then/catch/finally、queueMicrotask、MutationObserver）之间不存在“谁更快”的竞争，而是严格的执行轮次嵌套关系：
- 每完成一个宏任务，必须清空当前全部微任务，才允许下一个宏任务入场
- 微任务可以链式触发新微任务（比如 Promise.then 里再 return Promise），这些新任务会加入本轮微任务队列末尾，继续执行直到队列为空
- 宏任务内部产生的新宏任务（如 setTimeout 嵌套），只能排到下一轮宏任务队列末尾，绝不会插队到当前轮
async/await 不是语法糖那么简单，它是微任务的“触发器”
await 后面的表达式一旦 resolve，其后代码就会被包装进微任务执行——不是立即执行，也不是等到下个宏任务，而是紧接在当前微任务队列清空后、下一个宏任务开始前：
- async 函数返回 Promise，await 等待的值被 resolve 后，后续语句会被放入微任务队列
- 多个 await 连续出现时，每个 resolve 都会触发一次微任务入列，但它们仍按顺序串行执行，不会并行
- 注意：await null 或 await 42 这类非 Promise 值，会直接进入微任务（等价于 Promise.resolve().then(...)）
浏览器与 Node.js 的事件循环差异不止“多几个阶段”
浏览器的事件循环相对扁平（宏任务 → 微任务 → 宏任务…），而 Node.js 的 libuv 实现了更细粒度的阶段划分：
立即学习“Java免费学习笔记（深入）”；
- Node.js 有 timers、pending callbacks、idle/prepare、poll、check、close callbacks 六个阶段，每个阶段结束后都检查微任务队列
- process.nextTick 是 Node.js 特有，它比 Promise.then 更早执行——它属于“当前操作结束后的下一次 tick”，优先级高于所有微任务
- 浏览器中没有 process.nextTick，但 queueMicrotask() 提供了与之行为最接近的标准 API
调试技巧：别只看 console，要盯住“执行时机”
控制台输出只是结果，真正关键的是任务何时被推入队列、何时被取出执行：
- 用 debugger 搭配调用栈观察：同步代码执行完后，暂停点若落在 Promise.then 里，说明它刚从微任务队列弹出
- 在 setTimeout 回调里加 debugger，再看此时 Promise.then 是否已执行——能直观验证“宏任务必须等微任务清空”
- 避免用 console.log 猜顺序；改用 performance.now() 打点记录各任务实际触发时间戳，对比更可靠
