JavaScript事件循环决定异步代码执行顺序：宏任务（如setTimeout）需等当前宏任务及所有微任务（如Promise.then、await后续、queueMicrotask）执行完毕才运行，UI渲染发生在宏任务与微任务清空之后、下一宏任务之前。
JavaScript事件循环不是“可选知识”，而是你写的每一行异步代码实际执行顺序的唯一决定者——不理解它，就等于在猜代码什么时候跑、为什么 DOM 没更新、为什么 setTimeout 总比 Promise.then 晚输出。
为什么 setTimeout(() => console.log(2), 0) 不是“立刻执行”
很多人以为设成 0 就等于同步执行，结果发现它总被 Promise.then 插队。这不是 bug，是事件循环的硬规则：
-
setTimeout回调属于宏任务，必须排队等当前宏任务（比如整个脚本）执行完 + 所有微任务清空后，才轮到它 - 哪怕延时是
0，它也进宏任务队列，不会跳过微任务 -
浏览器还可能把
0延时强制提升为最小有效值（如 4ms），但关键不在这里——根本原因是任务类型不同
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出：1 → 4 → 3 → 2
async/await 的 await 后代码到底在哪执行
await 不是暂停函数，而是把后续代码包装成微任务——这决定了它的执行时机比你直觉中更“靠后”，但又比 setTimeout 更早：
-
await后面的语句不会出现在当前调用栈，而是在当前宏任务结束后、下一个宏任务开始前执行 - 如果
await等的是一个已 resolve 的 Promise，那后续代码几乎“紧接”同步代码之后，但仍在所有微任务清空阶段 - 错误写法：
await fetch(...); document.querySelector(...).innerText = 'done';—— DOM 更新可能还没触发，因为渲染在微任务之后、下一轮宏任务之前
console.log('script start');
async function foo() {
console.log('async start');
await Promise.resolve();
console.log('async end');
}
foo();
console.log('script end');
// 输出：script start → async start → script end → async end
什么时候该用 queueMicrotask 而不是 setTimeout
当你需要“在当前任务结束、但还不想等到下一轮宏任务”时，queueMicrotask 是精准控制微任务插入点的唯一标准 API（Promise.resolve().then 是等效但略重的替代）：
立即学习“Java免费学习笔记（深入）”；
-
queueMicrotask创建的回调和Promise.then处于同一微任务队列，优先级完全一致 - 比
Promise.resolve().then更轻量，无 Promise 构造开销，适合高频、简单调度 - 不能用于跨帧协调（比如等 DOM 渲染完成），那是
requestAnimationFrame的职责；微任务在渲染前就执行完了 - 警惕无限递归：
queueMicrotask(() => queueMicrotask(...))会卡死主线程，因为微任务队列必须清空才进入下一宏任务
console.log('before');
queueMicrotask(() => console.log('micro1'));
queueMicrotask(() => console.log('micro2'));
console.log('after');
// 输出：before → after → micro1 → micro2
UI 渲染和事件循环的关系常被忽略
浏览器的 UI 渲染不是微任务，也不是宏任务，而是一个独立阶段——它发生在“一个宏任务执行完 + 所有微任务清空之后、下一个宏任务开始之前”。这个间隙，就是你唯一能观察到真实 DOM 更新的窗口：
- 你在
Promise.then里改了innerHTML，但马上getBoundingClientRect()可能还是旧值——因为渲染还没发生 - 想等渲染完成？得用
requestAnimationFrame（下一帧）或await new Promise(requestAnimationFrame) -
MutationObserver回调也是微任务，但它监听的是 DOM 变更记录，不是渲染结果；变更记录触发后，仍需等渲染帧
最易被忽视的一点：事件循环没有“渲染任务”的概念，渲染是浏览器在事件循环间隙主动插入的步骤，开发者无法直接调度，只能感知。
