JavaScript事件循环按“宏任务→清空微任务队列→下一宏任务”循环执行；setTimeout(0)不立即执行，因需等当前宏任务及所有微任务完成；Node.js有6阶段模型且含process.nextTick，浏览器则无。
JavaScript 的事件循环不是“等所有同步代码跑完再执行异步”，而是持续轮询、分阶段调度任务的实时机制。它不保证 setTimeout 精确在 N 毫秒后执行，也不让 Promise.then 一定比 setTimeout 先运行——关键看当前宏任务是否结束、微任务队列是否清空。
宏任务和微任务的执行顺序怎么定
每次事件循环从一个宏任务开始（如脚本初始化、setTimeout 回调、setInterval 回调、I/O 回调），执行完后立即清空全部微任务队列（Promise.then、MutationObserver、queueMicrotask），再取下一个宏任务。
常见误解是“微任务优先级更高”，其实更准确的说法是：**每个宏任务结束后，引擎强制插入一次微任务清空步骤，且不可中断**。
-
setTimeout和Promise.resolve().then()同时注册，后者一定先执行 - 连续两个
Promise.then会按注册顺序依次进入微任务队列，不会被中间插入的宏任务打断 -
await后续代码会被包装成微任务，等价于Promise.then
为什么 setTimeout(0) 不会立刻执行
setTimeout(fn, 0) 只是把 fn 推入宏任务队列，等待当前宏任务+全部微任务执行完毕后，才可能被执行。浏览器还有最小延迟限制
这和 queueMicrotask(fn) 有本质区别：后者直接进微任务队列，下一轮微任务清空时就执行。
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出：1 → 4 → 3 → 2
Node.js 和浏览器的事件循环差异在哪
Node.js 的事件循环有 6 个明确阶段（timers、pending callbacks、idle/prepare、poll、check、close callbacks），而浏览器没有严格划分阶段，只遵循“宏任务 → 微任务 → 宏任务…”的基本节奏。
关键差异点：
-
setImmediate（Node.js 特有）在 check 阶段执行，总在setTimeout(..., 0)之后（即使时间相同） -
process.nextTick（Node.js）在当前操作结束后、任何微任务前执行，优先级高于Promise.then - 浏览器无
setImmediate和process.nextTick，但支持queueMicrotask
哪些操作会意外创建微任务
除了显式使用 Promise 或 queueMicrotask，以下情况也会触发微任务，容易被忽略：
-
async函数返回的 Promise 被 resolve/reject 时，其await后续逻辑作为微任务入队 -
MutationObserver的回调属于微任务（常用于监听 DOM 变化） -
document.write在某些场景下会隐式触发微任务（已废弃，但旧代码中可能遇到） - 部分 Web API 如
IntersectionObserver的回调也是微任务（规范未强制，但主流实现如此）
真正难调试的，往往是这些“看不见”的微任务堆积，导致 UI 更新延迟或状态错乱——比如在 Promise.then 里反复修改同一个 DOM 元素，却没意识到所有修改都挤在同一个渲染帧之前执行。
