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的回调，则会进入微任务队列。
立即学习“Java免费学习笔记（深入）”；
事件循环的核心逻辑是这样的：
所以，宏任务队列的执行顺序就是：一个接一个地来，每次只处理一个，然后给微任务和渲染机会，再处理下一个。
这真的是一个非常核心的问题，我发现很多人在初学JS异步时，都会在这里卡壳。理解宏任务和微任务的区别与协作，是掌握事件循环的关键。
宏任务，你可以看作是“大块”的任务，它们通常代表着独立的、耗时较长的操作。典型的宏任务包括：
setTimeout() 和 setInterval() 的回调。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）。
我个人在调试一些复杂的异步代码时，会习惯性地在脑海里模拟一个事件循环周期，这真的很有用。一个典型的事件循环周期大致是这样的：
setTimeout、fetch、addEventListener或者创建了Promise等异步API，它们会被交给浏览器或Node.js环境的对应模块（Web APIs）去处理。setTimeout的定时器到期，fetch请求返回数据），它们的回调函数并不会立即执行，而是被放入各自的队列。setTimeout的回调进入宏任务队列，Promise.then()的回调进入微任务队列。这个周期模型解释了为什么setTimeout(fn, 0)并不意味着fn会立即执行，它必须等待当前宏任务执行完毕，所有微任务清空，甚至可能等待一次渲染，才能轮到它。理解这个流程，对于预测代码执行顺序，尤其是涉及UI更新和复杂异步逻辑时，至关重要。
这是一个非常常见的开发者困惑，也是我经常被问到的问题。setTimeout(callback, delay)中的delay参数，它设定的不是精确的执行时间，而是一个最小延迟时间。这意味着，callback函数将会在delay毫秒后被添加到宏任务队列中，但它何时真正被执行，则取决于当前事件循环的状态，以及宏任务队列中是否有其他任务在排队。
有几个主要因素会导致setTimeout的实际执行时间比预期更长：
主线程阻塞：如果当前正在执行的宏任务（或者微任务）非常耗时，比如有大量的计算，或者长时间的同步循环，那么它会“霸占”主线程。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出现，因为它被前面的同步循环阻塞了。
宏任务队列中排队：即使没有长时间阻塞的同步代码，如果宏任务队列中已经有很多任务在等待（例如，大量的用户事件、网络回调），那么你的setTimeout回调也必须等待在它之前进入队列的其他宏任务执行完毕。事件循环一次只取一个宏任务。
浏览器最小延迟限制：在某些浏览器环境中，特别是嵌套的setTimeout（setTimeout里再setTimeout）或者非活动标签页，浏览器可能会强制一个最小的延迟时间，比如HTML5规范规定嵌套的setTimeout最小延迟为4ms。这是一种优化，旨在减少CPU和电池消耗。
渲染周期：在浏览器环境中，每次宏任务执行完毕且微任务队列清空后，浏览器有机会进行一次渲染。如果页面有大量的DOM操作或者复杂的CSS动画，渲染过程本身也需要时间，这也会间接导致下一个宏任务的延迟。
所以，当你使用setTimeout时，最好把它看作是一个“在我能处理的时候，尽快地，但不早于delay毫秒后执行”的请求。对于那些对时间精度要求极高的场景（比如游戏动画），通常会使用requestAnimationFrame，因为它更与浏览器的渲染周期同步，提供更平滑的动画效果。但即便如此，requestAnimationFrame也仍然受制于主线程的阻塞。理解这些不确定性，能帮助我们更好地设计和调试异步代码，避免因为不切实际的期望而陷入困境。
以上就是JavaScript中宏任务队列的执行顺序是什么的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
747
收藏
