宏任务执行顺序解析

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《宏任务执行顺序详解》，聊聊，我们一起来看看吧！

JavaScript中宏任务队列的执行顺序是“一次一个来”，即主线程空闲且所有微任务执行完毕后，事件循环从宏任务队列取出一个任务执行。1. 宏任务包括setTimeout、setInterval、I/O操作、用户事件和UI渲染等；2. 微任务如Promise.then、MutationObserver优先级更高，会在当前宏任务结束后立即清空微任务队列；3. 每次执行完一个宏任务后，事件循环会检查并执行所有可用微任务，再考虑渲染和下一个宏任务。这种机制确保异步操作有序执行，并影响代码运行顺序与性能优化策略。

JavaScript中宏任务队列的执行顺序，简单来说，它是一个“一次一个来”的队列。当主线程空闲下来，并且所有微任务都执行完毕后，事件循环会从宏任务队列中取出一个任务来执行。这个过程会不断重复，确保浏览器能处理各种异步操作，比如用户交互、网络请求和定时器。

解决方案

要深入理解宏任务队列的执行顺序，我们得先把握JavaScript的事件循环（Event Loop）机制。想象一下，你有一个主线任务（同步代码），它会一直在调用栈（Call Stack）里跑。当遇到像setTimeout、setInterval、I/O操作（比如网络请求完成）、UI渲染或者用户事件（点击、输入）这些异步任务时，它们并不会立即执行。相反，它们会被“甩”给Web APIs（浏览器提供的接口）处理。

当这些异步操作完成时，它们的回调函数并不会直接回到调用栈，而是被放入不同的队列。setTimeout、setInterval的回调，以及用户事件和网络请求的回调，通常会被放入宏任务队列（或者更准确地说，是任务队列，因为它主要处理宏任务）。而像Promise的then/catch/finally回调、MutationObserver的回调，则会进入微任务队列。

事件循环的核心逻辑是这样的：

1. 执行当前宏任务（比如初始的脚本代码）。
2. 当当前宏任务执行完毕，调用栈清空。
3. 检查微任务队列，将其中所有微任务依次执行完毕。这是关键，微任务的优先级高于宏任务，且一个宏任务结束后，会清空所有微任务。
4. 执行浏览器渲染（如果需要的话）。
5. 从宏任务队列中取出一个（注意，是一个）等待时间最长的宏任务，将其推入调用栈执行。
6. 重复步骤2-5。

所以，宏任务队列的执行顺序就是：一个接一个地来，每次只处理一个，然后给微任务和渲染机会，再处理下一个。

宏任务与微任务：它们在事件循环中如何协同工作？

这真的是一个非常核心的问题，我发现很多人在初学JS异步时，都会在这里卡壳。理解宏任务和微任务的区别与协作，是掌握事件循环的关键。

宏任务，你可以看作是“大块”的任务，它们通常代表着独立的、耗时较长的操作。典型的宏任务包括：

• setTimeout() 和 setInterval() 的回调。
• UI 渲染事件（例如，当浏览器需要重绘页面时）。
• I/O 操作（比如文件读写、网络请求完成后的回调）。
• 用户交互事件（点击、滚动、键盘输入等）。
• requestAnimationFrame 的回调（虽然它与渲染紧密相关，但其调度机制使其行为更像一个特殊的宏任务，通常在渲染前执行）。
• 初始的脚本执行本身，也被视为一个宏任务。

而微任务，则是“小而精”的任务，它们通常与当前正在执行的宏任务紧密关联，并且具有更高的优先级。常见的微任务有：

• Promise.prototype.then()、.catch()、.finally() 的回调。
• MutationObserver 的回调（用于监听DOM变化）。
• queueMicrotask() 方法添加的任务。

它们之间的协同关系是这样的：当一个宏任务执行完毕后，事件循环不会立即跳到下一个宏任务。它会先暂停，去检查微任务队列。如果微任务队列中有任务，它会把队列里的所有微任务全部执行完毕，直到队列清空。只有当微任务队列也清空后，事件循环才会考虑是否进行浏览器渲染，然后才会从宏任务队列中取出下一个宏任务来执行。

这种机制意味着，如果你在一个setTimeout里又创建了一个Promise，这个Promise的回调会在下一个setTimeout执行之前，甚至在浏览器渲染之前，就被执行掉。这对于需要高优先级执行的回异步操作，或者需要确保在下一次UI更新前完成的操作，提供了非常强大的控制能力。

console.log('Start'); // 宏任务1 - 初始脚本

setTimeout(() => {
  console.log('setTimeout 1'); // 宏任务2
  Promise.resolve().then(() => {
    console.log('Promise inside setTimeout'); // 微任务
  });
}, 0);

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

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

console.log('End'); // 宏任务1 - 初始脚本

输出会是： Start End Promise 1 setTimeout 1 Promise inside setTimeout setTimeout 2

这清楚地展示了微任务（Promise 1）在当前宏任务（初始脚本）结束后立即执行，然后才轮到下一个宏任务（setTimeout 1），而那个宏任务内部产生的微任务（Promise inside setTimeout）又会在该宏任务结束前被处理掉，最后才轮到再下一个宏任务（setTimeout 2）。

理解JavaScript运行时：一个典型的事件循环周期是怎样的？

我个人在调试一些复杂的异步代码时，会习惯性地在脑海里模拟一个事件循环周期，这真的很有用。一个典型的事件循环周期大致是这样的：

1. 初始脚本执行 (宏任务)：当你的JS文件被加载并开始执行时，这本身就是一个宏任务。所有同步代码都会在这里被执行，直到调用栈为空。
2. 遇到异步API：在同步代码执行过程中，如果你调用了像setTimeout、fetch、addEventListener或者创建了Promise等异步API，它们会被交给浏览器或Node.js环境的对应模块（Web APIs）去处理。
3. 回调入队：当这些异步操作完成时（例如，setTimeout的定时器到期，fetch请求返回数据），它们的回调函数并不会立即执行，而是被放入各自的队列。setTimeout的回调进入宏任务队列，Promise.then()的回调进入微任务队列。
4. 调用栈清空：当前宏任务（比如初始脚本）执行完毕，调用栈为空。
5. 微任务阶段：事件循环会立即检查微任务队列。如果里面有任务，它会把所有微任务一个接一个地取出来，推入调用栈执行，直到微任务队列完全清空。这是一个“清空式”操作，而不是“取一个”操作。
6. 渲染阶段 (浏览器环境特有)：在浏览器环境中，微任务队列清空后，如果浏览器判断有必要进行页面重绘（比如DOM发生了变化），它会执行一次渲染。这通常发生在下一个宏任务开始之前。
7. 选择下一个宏任务：渲染完成后（或者在Node.js中微任务清空后），事件循环会从宏任务队列中选择一个等待时间最长（或者说，最先到达队列）的宏任务，将其推入调用栈执行。
8. 循环往复：重复步骤4-7，周而复始，直到宏任务队列和微任务队列都清空，并且没有新的异步事件发生。

这个周期模型解释了为什么setTimeout(fn, 0)并不意味着fn会立即执行，它必须等待当前宏任务执行完毕，所有微任务清空，甚至可能等待一次渲染，才能轮到它。理解这个流程，对于预测代码执行顺序，尤其是涉及UI更新和复杂异步逻辑时，至关重要。

为什么我的setTimeout有时会延迟？深入探讨宏任务调度的不确定性

这是一个非常常见的开发者困惑，也是我经常被问到的问题。setTimeout(callback, delay)中的delay参数，它设定的不是精确的执行时间，而是一个最小延迟时间。这意味着，callback函数将会在delay毫秒后被添加到宏任务队列中，但它何时真正被执行，则取决于当前事件循环的状态，以及宏任务队列中是否有其他任务在排队。

有几个主要因素会导致setTimeout的实际执行时间比预期更长：

1. 主线程阻塞：如果当前正在执行的宏任务（或者微任务）非常耗时，比如有大量的计算，或者长时间的同步循环，那么它会“霸占”主线程。setTimeout的回调即使已经达到延迟时间并进入了宏任务队列，也必须等待当前这个耗时的任务执行完毕，调用栈清空，微任务队列清空后，才能轮到它。这就导致了额外的延迟。

   console.log('Start heavy task');
   let i = 0;
   while (i < 1000000000) { // 模拟一个非常耗时的同步操作
     i++;
   }
   console.log('Heavy task finished');
   
   setTimeout(() => {
     console.log('setTimeout executed after heavy task');
   }, 0); // 尽管是0ms，也会在重任务后执行
   
   console.log('End script');

   你会发现setTimeout executed after heavy task会远晚于End script出现，因为它被前面的同步循环阻塞了。

2. 宏任务队列中排队：即使没有长时间阻塞的同步代码，如果宏任务队列中已经有很多任务在等待（例如，大量的用户事件、网络回调），那么你的setTimeout回调也必须等待在它之前进入队列的其他宏任务执行完毕。事件循环一次只取一个宏任务。

3. 浏览器最小延迟限制：在某些浏览器环境中，特别是嵌套的setTimeout（setTimeout里再setTimeout）或者非活动标签页，浏览器可能会强制一个最小的延迟时间，比如HTML5规范规定嵌套的setTimeout最小延迟为4ms。这是一种优化，旨在减少CPU和电池消耗。

4. 渲染周期：在浏览器环境中，每次宏任务执行完毕且微任务队列清空后，浏览器有机会进行一次渲染。如果页面有大量的DOM操作或者复杂的CSS动画，渲染过程本身也需要时间，这也会间接导致下一个宏任务的延迟。

所以，当你使用setTimeout时，最好把它看作是一个“在我能处理的时候，尽快地，但不早于delay毫秒后执行”的请求。对于那些对时间精度要求极高的场景（比如游戏动画），通常会使用requestAnimationFrame，因为它更与浏览器的渲染周期同步，提供更平滑的动画效果。但即便如此，requestAnimationFrame也仍然受制于主线程的阻塞。理解这些不确定性，能帮助我们更好地设计和调试异步代码，避免因为不切实际的期望而陷入困境。

好了，本文到此结束，带大家了解了《宏任务执行顺序解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！