微任务执行顺序详解

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《微任务嵌套执行顺序解析》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

JavaScript中微任务的嵌套执行顺序是：1. 执行一个宏任务；2. 清空当前微任务队列，期间新加入的微任务也会被立即处理，直到队列为空；3. 渲染页面；4. 执行下一个宏任务。Promise.then、MutationObserver、queueMicrotask及async/await等API会创建微任务，确保异步操作连续执行，避免被宏任务打断，这对优化DOM更新、管理异步流程、调试和性能优化至关重要。

理解JavaScript中微任务的嵌套执行顺序，其实就是明白在一个事件循环的“回合”里，微任务队列是如何被清空的：当一个宏任务（比如脚本的初始执行、一个setTimeout的回调）开始时，它会执行直到完成。在这个过程中，任何被创建的微任务（比如Promise.then()的回调）都不会立即执行，而是被添加到当前事件循环的微任务队列里。而这个“嵌套”的关键在于，当当前宏任务执行完毕后，事件循环并不会马上进入下一个宏任务或渲染阶段，而是会先一口气把微任务队列里所有的任务都执行完。如果在这个清空微任务队列的过程中，又有新的微任务被添加到队列里，它们也会被排队，并且在当前这个“回合”中被立即处理，直到队列完全清空，才会考虑下一个宏任务。

解决方案

要深入理解JavaScript中微任务的嵌套执行，我们可以这样看：JavaScript的事件循环是个永不停歇的机器，它主要处理两种任务：宏任务（macrotasks）和微任务（microtasks）。每次事件循环迭代（或者说，每个“回合”），都会从宏任务队列中取出一个任务来执行。

核心的执行流程是这样的：

1. 执行一个宏任务：比如整个脚本的首次运行，或者一个setTimeout、setInterval、I/O回调等。
2. 清空微任务队列：当这个宏任务执行完毕后，JavaScript引擎不会立即去处理下一个宏任务。它会暂停，转而检查并执行所有当前微任务队列中的任务。这里就是“嵌套”的精髓所在——如果一个微任务在执行过程中又创建了新的微任务，这些新的微任务会立即被添加到当前微任务队列的末尾，并会在本次微任务队列清空周期内被执行。这个过程会持续进行，直到微任务队列完全为空。
3. 渲染：如果浏览器有渲染需求，它可能会在清空微任务队列之后进行页面渲染。
4. 下一个宏任务：完成渲染后，事件循环才会进入下一个宏任务的执行。

这意味着，微任务拥有比宏任务更高的优先级，它们总是在当前宏任务执行完毕后，下一个宏任务开始之前，被彻底地执行。这种机制确保了某些异步操作（如Promise链）的连续性和可预测性，避免了在中间被其他宏任务或渲染打断。

为什么理解微任务嵌套执行对前端开发至关重要？

作为开发者，我个人觉得，对微任务嵌套执行的理解，简直就是我们写出健壮、高效前端代码的基石。你想想看，很多时候我们写的异步逻辑，特别是涉及到数据获取、DOM更新和用户交互时，如果对事件循环和微任务的优先级一知半解，那代码行为就可能变得难以预测。

首先，它直接影响UI的响应性和更新时机。比如，你可能希望一系列Promise操作完成后，再统一更新DOM。如果Promise的回调是微任务，你就能确保这些更新会在当前事件循环周期内完成，而且是在浏览器有机会渲染之前。这对于避免不必要的重绘和回流，优化用户体验非常关键。否则，你可能会遇到“闪烁”或者更新不及时的问题。

其次，它能帮助我们更好地管理异步数据流。在处理复杂的异步操作链，比如级联的网络请求时，理解微任务能让你更精确地控制数据处理的顺序。你不会担心一个Promise的回调在执行过程中，被一个不相关的setTimeout或者其他宏任务插队，导致数据状态不一致。

再来，这关乎调试和错误追踪。当异步代码出问题时，如果不知道微任务的执行时机，你可能根本摸不着头脑，不知道为什么某些代码明明写在前面，却在后面执行，或者某些状态更新为什么没有按预期发生。深入理解这个机制，能让你更准确地定位问题，预测代码的执行路径。

最后，它也关系到性能优化。虽然微任务比宏任务优先级高，但如果在一个微任务中又创建了大量新的微任务，并且这些微任务又执行了耗时的操作，那么它们会长时间霸占主线程，导致页面卡顿，用户界面无响应。这就像你在一个回合里，不停地给自己加任务，结果这个回合永远都结束不了，或者说，结束得特别慢。所以，了解它能帮助我们避免写出“阻塞”代码。

哪些常见的JavaScript API会产生微任务？

日常开发中，我们最常打交道、会产生微任务的JavaScript API主要有那么几个：

最典型的，也是我们用得最多的，就是Promise.prototype.then()、catch()和finally()。当你调用promise.then()时，传入的回调函数并不会立即执行，而是被安排成一个微任务，等待当前宏任务执行完毕后，才会被推入微任务队列。这也是为什么Promise能实现链式调用，并且其回调总能在一个连续的逻辑流中执行，而不会被其他宏任务打断。

其次是MutationObserver。这个API允许我们监听DOM树的变化。当DOM发生变化时，MutationObserver的回调函数也会被安排成一个微任务来执行。这非常有用，因为它确保了DOM的变化能够被“批量”处理，而且处理时机是在当前脚本执行完毕、浏览器准备渲染之前，这对于前端框架（比如React、Vue）进行高效的DOM更新和协调工作至关重要。

然后是比较新的queueMicrotask()。这是一个明确用于调度微任务的API。它提供了一种直接将函数作为微任务排队的机制，而不需要依赖Promise或其他间接方式。当你需要确保某个操作在当前事件循环的微任务阶段执行，而不是等到下一个宏任务时，它就派上用场了。这在一些底层库或者需要精确控制执行时机的场景下非常有用。

当然，还有async/await。虽然它们看起来是同步的代码，但本质上是基于Promise的语法糖。await关键字会暂停async函数的执行，并将后续代码包装成一个微任务。当await的Promise解决后，这个微任务就会被推入队列，等待执行。所以，async/await的代码执行顺序也完全遵循微任务的规则。

在Node.js环境中，还有一个非常重要的类似微任务的机制是process.nextTick()。虽然它严格来说不是浏览器环境下的微任务，但它的行为和优先级与微任务非常相似，甚至比微任务的优先级还要高，会在当前操作的“tick”结束时立即执行，在所有微任务之前。不过，对于浏览器前端开发来说，我们主要关注前面提到的那几个。

如何通过代码示例演示微任务的嵌套执行？

要直观地感受微任务的嵌套执行，我们直接上代码，用console.log来追踪执行顺序，这是最简单也最有效的方法。

示例一：基础的Promise链与setTimeout

console.log('脚本开始'); // 宏任务1

setTimeout(() => {
  console.log('setTimeout 回调'); // 宏任务2
}, 0);

Promise.resolve().then(() => {
  console.log('Promise.then 1'); // 微任务1
  Promise.resolve().then(() => {
    console.log('Promise.then 2 (嵌套)'); // 微任务2
  });
}).then(() => {
  console.log('Promise.then 3'); // 微任务3
});

console.log('脚本结束'); // 宏任务1

预期输出分析：

1. '脚本开始'：同步代码，立即执行。
2. '脚本结束'：同步代码，立即执行。setTimeout和Promise.then的回调都被安排到队列中，但它们不会阻塞当前脚本的执行。
3. Promise.then 1：当前宏任务（整个脚本的执行）完成后，事件循环开始清空微任务队列。Promise.then 1是队列中的第一个。
4. Promise.then 2 (嵌套)：在Promise.then 1执行时，它又创建了一个新的微任务（Promise.then 2）。这个新的微任务会立即被添加到当前微任务队列的末尾。因此，它会在Promise.then 1之后，但在任何下一个宏任务之前执行。
5. Promise.then 3：这是Promise.then 1之后的下一个.then，它也是一个微任务，会紧接着在Promise.then 2之后执行，因为它们都属于当前批次的微任务队列清空。
6. setTimeout 回调：所有微任务清空后，事件循环才会去宏任务队列中取出下一个任务，也就是setTimeout的回调。

所以，实际的控制台输出会是：

脚本开始
脚本结束
Promise.then 1
Promise.then 2 (嵌套)
Promise.then 3
setTimeout 回调

这个例子清晰地展示了微任务（包括嵌套创建的微任务）会在当前宏任务结束后被完全清空，然后才会轮到下一个宏任务。

示例二：使用queueMicrotask

console.log('Start');

setTimeout(() => {
  console.log('setTimeout callback');
}, 0);

queueMicrotask(() => {
  console.log('queueMicrotask 1');
  queueMicrotask(() => {
    console.log('queueMicrotask 2 (nested)');
  });
});

Promise.resolve().then(() => {
  console.log('Promise.then from resolve');
});

console.log('End');

预期输出分析：

1. 'Start'：同步代码。
2. 'End'：同步代码。
3. 'queueMicrotask 1'：当前宏任务（整个脚本）执行完，开始清空微任务队列。queueMicrotask 1被执行。
4. 'queueMicrotask 2 (nested)'：在queueMicrotask 1执行时，又调度了一个新的微任务。它会立即被添加到队列末尾，并在当前批次中执行。
5. 'Promise.then from resolve'：Promise.resolve().then()的回调也是一个微任务，它会在所有queueMicrotask微任务之后执行，因为它们都在同一个微任务队列中。
6. 'setTimeout callback'：所有微任务都清空后，事件循环才会处理宏任务队列中的setTimeout回调。

实际输出：

Start
End
queueMicrotask 1
queueMicrotask 2 (nested)
Promise.then from resolve
setTimeout callback

这两个例子都很好地说明了微任务的“嵌套”特性：在清空微任务队列时，新加入的微任务也会立即被处理，直到队列为空，这确保了它们在宏任务之间的高优先级执行。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。