17370845950

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 回调）
• 立即检查并执行所有已入队的微任务（先进先出，但必须一次清空）
• 渲染（如果需要）
• 取下一个宏任务，重复

这意味着：

• 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 卡顿：它们全挤在同一个宏任务之后，没给渲染留机会。