JavaScript事件循环：宏任务与微任务执行顺序全解析

1. 项目概述：从“异步”到“有序”的底层逻辑

如果你写过JavaScript，尤其是处理过网络请求、定时器或者事件监听，那你肯定对“异步”这个概念不陌生。我们常说JS是单线程的，但浏览器却能同时做很多事，这背后的功臣就是事件循环（Event Loop）。而“宏任务”和“微任务”，正是事件循环这个精密调度系统中的两个核心队列，它们决定了代码的执行顺序。理解它们，不是死记硬背面试题，而是为了在实战中，当你的 setTimeout 回调没有按预期执行，或者 Promise 的 then 方法“抢跑”时，你能一眼看穿问题所在，写出可预测、高性能的代码。

简单来说，你可以把事件循环想象成一个永不休息的餐厅服务员（主线程）。他的工作流程是：从“宏任务”队列（比如客人点餐）里取一个任务处理，处理完后，他会立刻检查“微任务”队列（比如客人要求加杯水、换张纸巾这类小需求），并一口气把所有微任务都处理完，然后再去取下一个宏任务。这个“处理完一个宏任务，就清空所有微任务”的规则，是理解一切异步顺序问题的钥匙。无论是Vue的 nextTick ，还是Node.js的 process.nextTick ，其底层原理都绕不开这对概念。

2. 核心概念深度解析：宏任务与微任务的定义与来源

2.1 宏任务：由宿主环境发起的“大块工作”

宏任务（MacroTask）代表了浏览器或Node.js环境需要执行的、离散的、独立的工作单元。你可以把它理解为事件循环每次“轮回”中，从任务队列里取出的那个待办事项。

常见的宏任务来源包括：

• 脚本执行 ：一个 <script> 标签内的整体代码块，本身就是一个宏任务。
• 用户交互事件 ： click , mousemove , keydown 等事件的回调。
• 定时器 ： setTimeout , setInterval 设定的回调。
• I/O操作 ：网络请求（如 fetch 、 XMLHttpRequest ）完成后的回调。
• 渲染事件 ：如 requestAnimationFrame （注意：它在一些实现中处于渲染阶段，但通常也视为一种宏任务）。
• MessageChannel 等Web API。

注意 ： setTimeout(fn, 0) 并不意味着立即执行，它只是告诉引擎：“请在大约0毫秒后，将 fn 作为一个新的宏任务放入队列”。这意味着它必须等待当前执行栈清空，并且当前宏任务产生的所有微任务都执行完毕后，才会轮到它。

2.2 微任务：由JavaScript引擎发起的“紧急后续工作”

微任务（MicroTask）是在当前宏任务执行结束后、下一个宏任务开始前，必须立即执行完毕的“小任务”。它们拥有更高的优先级，用于处理一些需要尽快执行的后续操作，通常与“承诺”（Promise）和“观察”（MutationObserver）相关。

常见的微任务来源包括：

• Promise回调 ： Promise.then() , Promise.catch() , Promise.finally() 中的回调函数。这是微任务最主要的来源。
• async/await ： await 表达式后面的代码，实际上会被引擎转换为 Promise.then() 的链式调用，因此也属于微任务。
• MutationObserver ：监听DOM变化的回调。
• queueMicrotask() ：HTML5标准提供的、显式将函数加入微任务队列的API。
• process.nextTick() ：这是Node.js环境中的一个特例，它的优先级甚至比普通的微任务还要高。

为什么需要微任务？ 设想一个场景：你监听了一个按钮的点击（宏任务），在回调里你发起了一个 fetch 请求并处理它的 Promise 。如果没有微任务机制， Promise 的回调会被当作下一个宏任务，这可能导致基于请求结果更新DOM的操作被延迟到很久之后，用户感知上会有“卡顿”。微任务机制确保了在当前交互上下文（宏任务）结束后，所有相关的后续状态更新能立即、连续地发生，从而提供更流畅的用户体验。

3. 事件循环机制的全流程拆解

理解了宏任务和微任务的定义，我们来看它们是如何在事件循环这个舞台上协同工作的。事件循环是一个持续运行的循环，其模型可以简化为以下步骤：

1. 执行一个宏任务 ：从宏任务队列（常被称为“任务队列”或“回调队列”）中取出最老的一个任务，推入调用栈（Call Stack）开始执行。这个任务可能是一段脚本、一个事件回调或一个定时器回调。
2. 执行栈清空 ：该宏任务的所有同步代码会依次执行，形成执行栈。
3. 微任务检查点 ：当这个宏任务的同步代码全部执行完毕，执行栈为空时，事件循环并不会立即去取下一个宏任务。它会进入 微任务检查点 。
4. 清空微任务队列 ：引擎会依次执行微任务队列中的所有任务，直到队列被清空。 关键点在于：在执行一个微任务的过程中，如果又产生了新的微任务（例如，在一个 then 回调里又返回了一个新的Promise），这些新产生的微任务也会被加入到当前队列的末尾，并在本次循环中被一并执行。 这个过程会一直持续到微任务队列完全为空。
5. 渲染更新（如需要） ：在浏览器环境中，清空微任务队列后，可能会进行页面的重排（Reflow）与重绘（Repaint）。 requestAnimationFrame 回调通常在这个阶段之前执行。
6. 循环往复 ：完成以上步骤后，事件循环会回到第1步，从宏任务队列中取出下一个任务，开始新的“轮回”。

这个流程可以用一个简单的伪代码表示：

while (eventLoop.waitForTask()) {
  // 1. 取一个宏任务
  const macroTask = eventLoop.getNextMacroTask();
  execute(macroTask); // 执行宏任务（同步代码）

  // 2. 清空微任务队列
  let microTask;
  while (microTask = eventLoop.getNextMicroTask()) {
    execute(microTask);
  }

  // 3. （浏览器中）渲染
  if (isRepaintTime()) {
    updateRendering();
  }
}

4. 经典代码执行顺序分析与实战

理论说再多，不如看代码。我们通过几个逐渐复杂的例子，来固化你对执行顺序的理解。

4.1 基础示例：宏任务 vs 微任务

console.log('script start'); // 1. 同步代码，立即执行

setTimeout(function() {
  console.log('setTimeout'); // 4. 宏任务，最后执行
}, 0);

Promise.resolve().then(function() {
  console.log('promise1'); // 3. 微任务，在同步代码后立即执行
}).then(function() {
  console.log('promise2'); // 微任务链中的下一个
});

console.log('script end'); // 2. 同步代码，立即执行

输出顺序： script start -> script end -> promise1 -> promise2 -> setTimeout

执行过程解析：

1. 整个脚本本身是一个宏任务。先执行所有同步代码，输出 script start 和 script end 。
2. 同步代码执行完毕，执行栈清空。开始处理微任务队列。
3. 微任务队列中有一个由 Promise.resolve().then(...) 产生的任务。执行它，输出 promise1 。
4. 执行第一个 then 回调时，又返回了一个新的Promise（隐式返回 undefined 的fulfilled Promise），其 then 回调（输出 promise2 ）作为一个 新的微任务 被加入到当前微任务队列的末尾。
5. 事件循环继续检查微任务队列，发现新任务，执行并输出 promise2 。此时微任务队列清空。
6. 开始下一个事件循环的宏任务阶段，取出 setTimeout 的回调并执行，输出 setTimeout 。

4.2 进阶示例：微任务的“插队”与连续执行

document.addEventListener('click', () => {
  console.log('click 1');
  Promise.resolve().then(() => console.log('promise from click 1'));
  setTimeout(() => console.log('timeout from click 1'), 0);
});

document.addEventListener('click', () => {
  console.log('click 2');
  Promise.resolve().then(() => console.log('promise from click 2'));
  setTimeout(() => console.log('timeout from click 2'), 0);
});

// 模拟用户点击一次
document.body.click();

输出顺序： click 1 -> click 2 -> promise from click 1 -> promise from click 2 -> timeout from click 1 -> timeout from click 2

执行过程解析：

1. document.body.click() 是同步代码，它会 同步地 触发所有绑定的事件处理函数。因此先输出 click 1 ，再输出 click 2 。注意，这两个 click 事件的回调是在 同一个宏任务 （即执行 click() 的这个脚本任务）中连续执行的，而不是两个独立的宏任务。
2. 当前宏任务（脚本执行）的同步代码全部完成。开始清空微任务队列。
3. 微任务队列中现在有两个任务： promise from click 1 和 promise from click 2 （按加入顺序）。依次执行，输出。
4. 微任务队列清空。进入下一个事件循环，从宏任务队列中取出第一个 setTimeout 回调执行，输出 timeout from click 1 。
5. 执行该宏任务后，微任务队列为空（本例中未产生新微任务）。
6. 再进入下一个事件循环，取出第二个 setTimeout 回调执行，输出 timeout from click 2 。

这个例子清晰地展示了： 用户交互事件回调如果被同步触发，它们属于同一个宏任务；其产生的微任务会在所有同源宏任务的同步代码之后、下一个宏任务之前被批量处理。

4.3 复杂示例：async/await 的实质

async/await 是语法糖，其本质是 Promise 和生成器的结合。 await 表达式会暂停 async 函数的执行，等待其后的表达式（通常是一个Promise）解决（settled），然后恢复执行。 关键点在于， await 后面的代码，相当于被包装到了 Promise.then() 的回调里，因此属于微任务。

async function async1() {
  console.log('async1 start'); // 2. 同步代码
  await async2(); // await 暂停，async2执行
  console.log('async1 end'); // 6. 微任务，在async2的Promise解决后执行
}
async function async2() {
  console.log('async2'); // 3. 同步代码
  // async函数默认返回一个Promise，这里相当于返回 Promise.resolve(undefined)
}

console.log('script start'); // 1. 同步代码

setTimeout(function() {
  console.log('setTimeout'); // 8. 宏任务，最后执行
}, 0);

async1();

new Promise(function(resolve) {
  console.log('promise1'); // 4. 同步代码（executor是同步执行的！）
  resolve();
}).then(function() {
  console.log('promise2'); // 7. 微任务
});

console.log('script end'); // 5. 同步代码

输出顺序： script start -> async1 start -> async2 -> promise1 -> script end -> async1 end -> promise2 -> setTimeout

执行过程解析：

1. 同步代码依次执行，输出 script start 。
2. 调用 async1() ，执行其内部同步代码，输出 async1 start 。
3. 执行 await async2() ，调用 async2() 函数，输出 async2 。 async2 函数返回一个已解决的Promise。此时， await 会让出线程， async1 函数中 await 之后的代码（ console.log('async1 end') ）被作为一个微任务放入队列 。
4. 继续执行外部同步代码，遇到 new Promise ，其执行器（executor）函数是同步执行的，因此输出 promise1 ，并调用 resolve() 。 resolve() 调用后，其 .then() 回调被作为另一个微任务放入队列。
5. 继续执行同步代码，输出 script end 。至此，当前宏任务的所有同步代码执行完毕。
6. 开始清空微任务队列。队列中有两个微任务：第一个是 async1 中 await 后面的代码，输出 async1 end ；第二个是 Promise 的 then 回调，输出 promise2 。
7. 微任务队列清空。进入下一个事件循环，执行 setTimeout 回调，输出 setTimeout 。

实操心得 ：很多同学会混淆 new Promise(executor) 中的 executor 函数和 .then() 回调。记住， executor 是 同步执行 的，用于初始化Promise的状态；而 .then()/catch()/finally() 的回调才是 异步的微任务 。 await 可以被看作是一个“语法上的暂停点”，其后的代码就是微任务。

5. 在框架与工程中的应用与避坑指南

理解了原理，我们来看看在真实项目，特别是现代前端框架中，如何应用并规避常见问题。

5.1 Vue.js 的 nextTick 原理

Vue的 nextTick 是一个非常重要的API，用于在下次DOM更新循环结束之后执行延迟回调。它的实现就巧妙地利用了微任务和宏任务的优先级。

Vue 2.x 内部会尝试按以下顺序选择 nextTick 的实现：

1. 首选微任务 ：如果环境支持 Promise ，则用 Promise.then() 。
2. 降级方案 ：如果不支持 Promise ，则尝试 MutationObserver （也是微任务）。
3. 宏任务兜底 ：如果都不支持，最后回退到 setImmediate 或 setTimeout(fn, 0) （宏任务）。

为什么优先使用微任务？ 因为Vue的DOM更新是异步的。当你修改响应式数据后，Vue并不会立即更新DOM，而是将这些更新操作推入一个队列。在同一个事件循环中，无论你修改了多少次数据，组件都只会在下一个 nextTick 时更新一次。使用微任务（如 Promise.then ）作为 nextTick 的载体，可以确保DOM更新在所有同步数据变更之后、下一个宏任务（如用户交互、网络回调）之前完成。这样，你在 nextTick 回调中就能获取到更新后的DOM，同时避免了不必要的渲染中间态，提升了性能和用户体验。

示例与避坑：

// 假设有一个响应式数据 this.msg = 'Hello'
this.msg = 'Changed';
console.log(this.$el.textContent); // 可能还是 'Hello'，DOM未更新
this.$nextTick(() => {
  console.log(this.$el.textContent); // 这里是 'Changed'，DOM已更新
});

5.2 在Node.js中的差异

Node.js的事件循环阶段比浏览器更复杂，分为 timers 、 pending callbacks 、 idle, prepare 、 poll 、 check 、 close callbacks 等多个阶段。但宏任务和微任务的核心思想不变。

需要特别注意的是 process.nextTick() ，它不属于任何事件循环阶段，而是在当前操作完成后、事件循环继续之前立即执行。 它的优先级高于由 Promise 产生的微任务 。

Promise.resolve().then(() => console.log('Promise'));
process.nextTick(() => console.log('nextTick'));
console.log('同步代码');
// 输出：同步代码 -> nextTick -> Promise

在Node.js中编写高性能服务时，滥用 process.nextTick 可能导致I/O饥饿，因为会一直执行 nextTick 队列而无法进入事件循环的下一个阶段。通常，对于立即的异步回调，使用 setImmediate （属于 check 阶段的宏任务）是更合适的选择。

5.3 常见性能陷阱与编码最佳实践

1. 避免在微任务中执行耗时操作 ：微任务队列会在当前宏任务结束后被一次性清空。如果一个微任务执行时间过长（例如进行复杂的计算或同步的密集循环），会阻塞页面渲染和后续宏任务的执行，导致页面“卡死”。对于耗时操作，应使用 setTimeout 或 Web Worker 将其拆分为独立的宏任务或放到其他线程。

2. 警惕微任务无限递归 ：在微任务中产生新的微任务，并且没有终止条件，会导致事件循环一直停留在微任务检查点，永远无法进入下一个宏任务和渲染阶段，造成页面无响应。

   // 危险示例！
   function infiniteMicrotask() {
     Promise.resolve().then(infiniteMicrotask);
   }
   infiniteMicrotask();
   // 从此，浏览器将卡死在此处
   

3. 合理拆分任务 ：对于需要处理大量数据的循环，可以考虑使用类似“分时”的技术，用 setTimeout 或 requestAnimationFrame 将任务拆分成多个小宏任务执行，给浏览器留出渲染和响应用户输入的时间。

   function processLargeArray(array, callback) {
     let chunkSize = 100;
     let index = 0;
     function doChunk() {
       let chunk = array.slice(index, index + chunkSize);
       // 处理chunk...
       index += chunkSize;
       if (index < array.length) {
         // 使用宏任务拆分，让出控制权
         setTimeout(doChunk, 0);
         // 或者使用 requestAnimationFrame 更平滑
         // requestAnimationFrame(doChunk);
       } else {
         callback();
       }
     }
     doChunk();
   }
   

4. 理解I/O回调的时机 ：网络请求（ fetch / axios ）的回调、文件读取回调等是宏任务。如果你在一个微任务（如Promise链）中发起多个并行请求，它们的回调会作为独立的宏任务，按完成顺序进入队列，你无法精确控制它们的执行顺序。

6. 调试技巧与问题排查实录

在实际开发中，遇到异步顺序问题如何调试？死记硬背执行顺序是不够的，你需要工具和方法。

6.1 利用浏览器开发者工具

现代浏览器的“Sources”面板或“Performance”面板是分析事件循环的利器。

1. 断点调试 ：在关键的 console.log 、 setTimeout 回调或 Promise.then 回调处打上断点，查看调用栈（Call Stack）。调用栈能清晰展示代码的执行路径，帮助你理解当前处于哪个任务的上下文中。
2. Performance面板录制 ：录制一段用户操作，在“Main”线程的可视化图表中，你可以看到一个个任务块（Task）。将鼠标悬停上去，可以看到是哪个函数发起的任务（如 setTimeout , click , Promise 等），以及任务的耗时。微任务通常不会单独显示为一个长条，但它们会在一个宏任务块内部执行。

6.2 典型问题排查清单

当你发现代码执行顺序不符合预期时，可以按以下清单自查：

6.3 一个真实的排查案例

场景 ：一个Vue组件中，在按钮点击事件里先修改了数据，然后马上用 $refs 去调用一个子组件的方法，但有时方法调用失败，提示子组件方法不存在。

初步分析 ：这很可能是因为数据修改触发了Vue的异步重新渲染，而用 $refs 访问子组件实例是同步的。在重新渲染完成前，旧的子组件实例可能已被销毁，新的实例还未挂载，导致 $refs 访问不到正确实例。

解决方案 ：使用 this.$nextTick 确保操作在DOM更新之后执行。

methods: {
  handleClick() {
    this.showNewComponent = true; // 触发异步渲染
    this.$nextTick(() => {
      // 此时新的子组件已挂载
      this.$refs.newChild.someMethod();
    });
  }
}

深层原理 ： this.$nextTick(callback) 将 callback 推入微任务队列。Vue的渲染更新（ Watcher 的更新）也被安排为微任务。由于微任务队列是先进先出（FIFO）的，所以当你在数据变更后立即调用 $nextTick ，你的回调会被排在整个组件渲染更新微任务 之后 ，从而保证了访问到的是最新的DOM和组件实例。

理解宏任务与微任务，最终目的是为了写出更可靠、性能更好的异步代码。它不是什么高深的魔法，而是JavaScript并发模型的基石。下次当你对代码执行顺序感到困惑时，不妨在纸上画一画事件循环的流程图：同步栈、宏任务队列、微任务队列。把代码块对号入座，一切都会变得清晰起来。记住这个黄金法则： 同步代码永远最先执行，然后清空所有微任务，最后再取下一个宏任务。 掌握了这个法则，你就掌握了JavaScript异步世界的秩序。