JavaScript事件循环先执行一个宏任务，再清空全部微任务队列，然后渲染，再取下一个宏任务；微任务如Promise.then总在当前宏任务后立即执行，而setTimeout等宏任务需等待下一轮。
宏任务和微任务的执行顺序怎么定？
JavaScript 的 Event Loop 不是按“先来后到”排队，而是严格区分 macro task（宏任务）和 micro task（微任务）两类。每次事件循环只取一个宏任务执行，但执行完它后，会清空当前所有微任务队列，再进入下一轮。
常见宏任务包括：setTimeout、setInterval、I/O、UI 渲染、script 整体代码块；
常见微任务包括：Promise.then/catch/finally、queueMicrotask、MutationObserver。
console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// 输出：1 → 4 → 3 → 2
注意：setTimeout 回调哪怕设为 0，也属于宏任务，必须等本轮微任务全部跑完才进下一轮。
为什么 Promise.then 总比 setTimeout 快？
不是因为“Promise 更快”，而是因为微任务在宏任务之间插入执行。Event Loop 的调度逻辑是：
- 执行一个宏任务（比如主脚本或某个
setTimeout回调） - 立即检查并执行所有已入队的微任务（先进先出，但必须一次清空）
- 渲染（如果需要）
- 取下一个宏任务，重复
这意味着：
立即学习“Java免费学习笔记（深入）”；
-
Promise.then注册的回调会被推入微任务队列，不参与宏任务排队 -
setTimeout回调被推入宏任务队列，要等至少一轮完整循环 - 即使两个回调都在同一行注册，
Promise.then仍会抢占执行时机
微任务没有“延迟”概念，只要入队就保证在当前宏任务结束后立即执行——这是它和 setTimeout(fn, 0) 的本质区别。
多个 Promise 链和 queueMicrotask 混用时怎么排？
所有微任务共享一个队列，按入队顺序执行，与类型无关。也就是说：Promise.then 和 queueMicrotask 是平级的，谁先调用谁先入队。
Promise.resolve().then(() => console.log('a'));
queueMicrotask(() => console.log('b'));
Promise.resolve().then(() => console.log('c'));
// 输出：a → b → c
但要注意：
-
Promise.then的回调是在 Promise 状态变为fulfilled后才入队（不是定义时） -
queueMicrotask是立即入队，哪怕写在Promise.then内部，也得等该then执行完才轮到它 - 如果有嵌套 Promise 或链式调用，每层
then都是新微任务，依次追加
UI 渲染和 requestAnimationFrame 在哪介入？
浏览器把 UI 渲染当作一个特殊的宏任务，在每个宏任务执行完毕、且微任务队列清空后触发。而 requestAnimationFrame（raf）是个例外：它不是微任务，也不是普通宏任务，而是由浏览器在下次重绘前统一调度的独立队列，优先级高于 setTimeout，但低于微任务。
console.log('start');
Promise.resolve().then(() => console.log('micro1'));
requestAnimationFrame(() => console.log('raf'));
setTimeout(() => console.log('timeout'), 0);
console.log('end');
// 典型输出：start → end → micro1 → raf → timeout
关键点：
-
raf回调不会被微任务阻塞，但它不参与 Event Loop 的标准队列调度 - 它依赖屏幕刷新率（通常 60fps），且只在页面可见时活跃
- 多次调用
requestAnimationFrame，浏览器只保留最后一次回调执行
微任务队列的“清空”行为容易被忽略——很多人以为它只是“插队执行一次”，其实它是阻塞后续宏任务的硬性步骤。这也解释了为什么大量 Promise.then 嵌套可能造成 UI 卡顿：它们全挤在同一个宏任务之后，没给渲染留机会。
