17370845950

JavaScript事件循环执行顺序取决于调用栈状态、任务队列及运行时实现；宏任务包括setTimeout、setInterval、setImmediate（Node.js）、I/O回调、UI渲染、postMessage、script脚本；微任务包括Promise.then/catch/finally、MutationObserver、queueMicrotask、async/await后续处理，且process.nextTick在Node.js中优先级最高。

JavaScript 的事件循环不是“先执行宏任务、再清空微任务队列”这么简单；真实执行顺序取决于当前调用栈是否为空、任务队列是否有待处理任务，以及浏览器或 Node.js 运行时的具体实现细节。

宏任务（macrotask）有哪些常见来源

宏任务是事件循环每次迭代中最多执行一个的任务单元。它们触发新一轮循环，也决定了代码的宏观节奏。

• setTimeout 和 setInterval 回调（即使延迟为 0）
• setImmediate（仅 Node.js）
• I/O 回调（如 fs.readFile 完成后）
• UI 渲染（浏览器中，通常在一轮宏任务结束后尝试进行）
• postMessage、MessageChannel 消息事件
• 整个 script 脚本本身（初始执行上下文）

微任务（microtask）的插入与执行时机

微任务在每次宏任务执行完、且调用栈清空后立即执行，直到微任务队列为空。它不触发新循环，但会抢占渲染和下个宏任务。

• Promise.then/catch/finally 回调（包括 Promise.resolve().then()）
• MutationObserver 回调
• queueMicrotask 显式入队的函数
• async 函数隐式返回的 Promise 的后续处理（即 await 后的代码会被包装进微任务）

注意：process.nextTick（Node.js）优先级高于其他微任务，但它不属于标准微任务队列，而是在当前操作结束、进入事件循环前立即执行——这导致它甚至早于 Prom

一个典型执行序列的实操验证

下面这段代码能清晰暴露宏任务与微任务的真实穿插关系：

console.log(1);

setTimeout(() => console.log(2), 0);

Promise.resolve().then(() => console.log(3));

Promise.resolve().then(() => {
  console.log(4);
  setTimeout(() => console.log(5), 0);
});

console.log(6);

输出顺序是：1 → 6 → 3 → 4 → 2 → 5。原因如下：

• 同步代码 console.log(1) 和 console.log(6) 立即执行
• 两个 Promise.then 被推入微任务队列，宏任务结束后立即执行，输出 3 和 4
• setTimeout 的回调被推入宏任务队列，要等当前宏任务+所有微任务完成后，才在下一轮循环中执行，输出 2
• 嵌套的 setTimeout 在 4 输出后才注册，因此它的回调排在下一个宏任务位置，输出 5

容易被忽略的关键点

微任务不是“比宏任务快”，而是“在宏任务退出后、下一轮开始前强制清空”。这意味着：

• 大量 Promise.then 链或频繁 queueMicrotask 可能阻塞 UI 渲染（浏览器中微任务执行期间不渲染）
• Node.js 中 process.nextTick 会打断微任务队列，造成与浏览器不一致的行为
• await 后面的语句不是“立刻执行”，而是被封装进一个微任务——所以 await Promise.resolve() 后的代码，总在当前同步代码之后、下一个宏任务之前运行
• 没有“微任务循环”，只有“微任务队列清空”：一旦开始执行微任务，就必须全部跑完，中途不会插入新的宏任务

真正影响行为的不是任务“类型”本身，而是它们被推入哪个队列、以及当前事件循环阶段是否允许该队列执行。