1. 从一次诡异的页面卡顿说起为什么你的代码“看起来”没执行那天下午我正在调试一个看似简单的用户交互功能点击一个按钮先弹出一个模态框然后紧接着在控制台打印一条日志。代码写得很直白我用了setTimeout来模拟一个异步操作然后在回调里打印日志。逻辑上模态框弹出后日志应该立刻出现。但实际运行起来我发现了一个奇怪的现象模态框确实弹出来了但控制台的日志要等上差不多一秒钟才姗姗来迟。这完全不符合我的预期setTimeout的延迟我明明设的是 0 毫秒啊这个看似微小的“延迟”让我一头扎进了 JavaScript 事件循环的深水区也让我彻底搞明白了宏任务和微任务这两个核心概念。它们不是面试八股文里的死记硬背而是实实在在影响你代码执行顺序、决定页面响应流畅度的幕后导演。很多前端开发者遇到的“为什么我的 Promise 回调比setTimeout先执行”、“为什么 Vue 的nextTick能确保 DOM 更新后执行”这类问题根源都在于此。简单来说你可以把 JavaScript 的执行环境想象成一个永不停止的循环我们称之为“事件循环”。这个循环有一个“任务队列”。但关键点在于这个队列不是只有一个而是至少分为两种优先级不同的队列宏任务队列和微任务队列。你的所有同步代码、setTimeout、setInterval、I/O 操作、UI 渲染等会被打包成一个个宏任务。而Promise.then、async/await、MutationObserver等操作产生的回调则会被打包成微任务。事件循环的核心规则可以浓缩为一句话每执行完一个宏任务就会立刻清空当前所有的微任务队列然后才会考虑执行下一个宏任务。我遇到的那个问题正是因为弹出模态框可能触发了重绘属于一次新的宏任务或宏任务的一部分后事件循环去检查并执行了其他微任务如果有的话然后才轮到我的setTimeout回调这个宏任务。理解这套机制不仅能帮你精准定位和修复上述的时序 Bug更能让你在编写高性能、响应迅速的异步代码时游刃有余。无论是优化长列表渲染、实现精准的动画时序还是理解现代前端框架如 Vue、React的更新机制宏任务和微任务都是你绕不开的底层基石。接下来我们就一层层剥开它的外壳看看这个“循环”到底是怎么转起来的。2. 解剖事件循环宏任务与微任务的运转舞台要理解宏任务和微任务我们必须先登上它们表演的舞台——事件循环。JavaScript 是单线程的这意味着它同一时间只能做一件事。为了处理异步操作比如网络请求、定时器而不阻塞主线程浏览器或 Node.js实现了一套精巧的协作机制这就是事件循环。2.1 单线程与异步的悖论单线程意味着代码按顺序执行。如果一段网络请求的代码同步执行那么在收到响应之前整个页面都会卡住用户无法进行任何操作这显然是无法接受的。为了解决这个问题JavaScript 将很多可能耗时的操作如setTimeout、fetch、DOM 事件委托给宿主环境浏览器的其他线程去处理。当这些操作完成后宿主环境会将对应的“回调函数”安排到某个队列中等待 JavaScript 主线程来执行。这个“安排回调”和“执行回调”的协调系统就是事件循环。2.2 事件循环的核心流程一个简化但足够准确的事件循环模型可以看作以下步骤的无限循环执行栈从宏任务队列中取出一个最老的宏任务比如一段script标签中的全局代码、或者一个setTimeout的回调将其推入执行栈开始执行。这个宏任务就是我们常说的“一个执行单元”。微任务检查点当这个宏任务执行完毕执行栈清空后事件循环不会立即去取下一个宏任务。它会进入一个关键阶段检查微任务队列。清空微任务队列事件循环会持续地从微任务队列中取出任务推入执行栈执行直到微任务队列被完全清空。这是一个“清仓”操作只要队列里有就全部执行完。渲染浏览器环境在浏览器中清空微任务队列后可能会进行页面的重新渲染Recalculate Style, Layout, Paint, Composite。注意渲染的时机并不固定浏览器会根据自己的策略如每秒60帧来安排但微任务清空后是一个常见的检查点。取下一个宏任务完成上述步骤后事件循环才会回到第一步从宏任务队列中取出下一个宏任务开始新一轮的循环。这个流程揭示了微任务的核心特性高优先级。微任务会在当前宏任务结束后、下一个宏任务开始前被“插队”执行完毕。2.3 宏任务与微任务的来源理解了流程我们来看看哪些操作会产生这两种任务常见的宏任务源包括主线程代码script标签内的同步代码本身就是一个宏任务。setTimeout/setInterval定时器回调。setImmediateNode.js 环境特有。I/O 操作如文件读写、网络请求完成后的回调注意fetch的 Promise 回调是微任务但其底层网络请求的完成事件调度可能关联宏任务。UI 渲染浏览器渲染管道本身可以被视为一个宏任务尽管细节更复杂。用户交互事件click、scroll、keydown等事件的回调。MessageChannel用于跨文档通信或 Web Worker 通信。常见的微任务源包括Promise.then()/Promise.catch()/Promise.finally()这是最主要的微任务来源。async/awaitawait之后的代码本质上相当于被包装在Promise.then中因此也是微任务。MutationObserver监听 DOM 变化的回调。queueMicrotask()一个显式将函数加入微任务队列的 API。process.nextTickNode.js 环境中优先级甚至高于微任务的特殊队列可以理解为“微微任务”。注意这里有一个非常重要的细节。new Promise()构造函数内部的执行器函数是同步执行的。只有它的resolve或reject后通过.then或.catch注册的回调函数才会被安排为微任务。console.log(1); // 同步属于当前宏任务 new Promise((resolve) { console.log(2); // 同步属于当前宏任务 resolve(); }).then(() { console.log(3); // 异步微任务 }); console.log(4); // 同步属于当前宏任务 // 输出顺序1, 2, 4, 33. 实战推演从经典面试题到真实场景理论说再多不如看代码。我们通过几个层层递进的例子来固化对执行顺序的理解。3.1 基础顺序题理解“清空微任务队列”这是最经典的面试题类型考察你对单一事件循环周期的理解。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); // 3.1 微任务紧接上一个微任务 }); console.log(script end); // 2. 同步代码宏任务执行顺序分析整个script是一个宏任务。依次执行同步代码输出script start和script end。执行过程中setTimeout的回调被安排到宏任务队列。两个Promise.then的回调被安排到微任务队列。当前宏任务script执行完毕。事件循环开始清空微任务队列。执行第一个微任务输出promise1。这个微任务执行完后又向微任务队列添加了第二个.then的回调输出promise2。关键点事件循环会持续清空微任务队列直到队列为空。所以它会立即取出并执行这第二个微任务输出promise2。微任务队列清空。此时可能进行渲染如果有必要。事件循环从宏任务队列中取出下一个任务即setTimeout的回调并执行输出setTimeout。最终输出script start-script end-promise1-promise2-setTimeout3.2 嵌套场景微任务在宏任务中的产生当微任务是在一个宏任务执行过程中产生时它依然会在当前宏任务结束后被立即执行而不是等到所有外层宏任务都完成。setTimeout(() { console.log(timeout1); // 宏任务2 Promise.resolve().then(() console.log(promise inside timeout1)); // 微任务2 }, 0); setTimeout(() { console.log(timeout2); // 宏任务3 }, 0); Promise.resolve().then(() console.log(promise1)); // 微任务1 console.log(global); // 同步代码宏任务1的一部分执行顺序分析第一个宏任务全局代码输出global。将两个setTimeout回调放入宏任务队列。将promise1回调放入微任务队列。宏任务结束清空微任务队列输出promise1。第二个宏任务第一个setTimeout回调输出timeout1。将promise inside timeout1回调放入微任务队列。该宏任务结束立刻清空微任务队列输出promise inside timeout1。第三个宏任务第二个setTimeout回调输出timeout2。最终输出global-promise1-timeout1-promise inside timeout1-timeout2这个例子清晰地展示了“每个宏任务之后都会清空其产生的所有微任务”的规则。promise inside timeout1并没有等到timeout2执行完才运行。3.3 结合 async/await语法糖的真相async/await是 Promise 的语法糖它让异步代码看起来像同步代码但其执行顺序依然严格遵守微任务规则。async function async1() { console.log(async1 start); // 同步 await async2(); // 关键点在这里 console.log(async1 end); // 微任务 } async function async2() { console.log(async2); // 同步 } console.log(script start); // 同步 setTimeout(() { console.log(setTimeout); // 宏任务 }, 0); async1(); new Promise(resolve { console.log(promise1); // 同步 resolve(); }).then(() { console.log(promise2); // 微任务 }); console.log(script end); // 同步关键点解析await async2()这行代码可以近似理解为Promise.resolve(async2()).then(() { // await 后面的代码在这里执行 console.log(async1 end); });所以console.log(async1 end)是被包装在一个Promise.then回调里的因此它是一个微任务。执行顺序分析同步代码依次执行输出script start,async1 start,async2,promise1,script end。同时setTimeout回调进入宏任务队列。await后面的代码async1 end进入微任务队列。Promise.then的回调promise2进入微任务队列。当前宏任务结束清空微任务队列。微任务队列中有两个任务async1 end和promise2。它们按进入队列的顺序执行输出async1 end,promise2。执行下一个宏任务setTimeout回调输出setTimeout。最终输出script start-async1 start-async2-promise1-script end-async1 end-promise2-setTimeout4. 在框架与工程中的实际应用理解了原理我们来看看它在实际开发中如何大显身手。这绝不是纸上谈兵而是解决实际痛点的利器。4.1 Vue.js 的 nextTick 原理Vue 2/3 中有一个著名的 APInextTick。它的作用是将回调延迟到下次 DOM 更新循环之后执行。在修改数据之后立即使用它然后等待 DOM 更新。它的实现就巧妙地利用了微任务和宏任务的优先级。Vue 内部在更新 DOM 时是异步的。当你修改一个响应式数据时Vue 不会立即更新 DOM而是将这个更新操作推进一个队列。在当前同步代码执行栈清空后即当前宏任务结束Vue 会清空这个更新队列这个过程本质上是执行了一系列的渲染 Watcher其中涉及 DOM 操作。这个“清空更新队列”的操作Vue 会尝试将其包装成一个微任务优先使用Promise.then或MutationObserver如果浏览器不支持则降级为宏任务如setTimeout。当你调用Vue.nextTick(callback)时Vue 会将你的callback函数也推入一个回调队列。在同一个事件循环中Vue 会先执行所有的数据更新微任务完成 DOM 的重新渲染。然后事件循环才会执行nextTick队列中的回调也是微任务。这就保证了你在nextTick回调中获取到的是更新后的 DOM。如果没有这套基于微任务的调度机制你可能需要手动使用setTimeout(fn, 0)来“猜测”DOM 何时更新完毕既不可靠效率也低。// Vue 示例 this.message Hello; // 触发异步 DOM 更新 console.log(this.$el.textContent); // 可能还是旧值 this.$nextTick(() { console.log(this.$el.textContent); // 这里一定是更新后的 Hello });4.2 避免长任务提升页面响应性由于 JavaScript 是单线程如果一个宏任务执行时间过长例如循环处理一个巨大的数组、执行复杂的计算它就会阻塞事件循环。在此期间微任务队列无法被清空新的用户交互点击、滚动也无法被响应因为交互事件也是宏任务页面就会“卡死”。最佳实践是将长任务拆解。微任务在这里可以作为一个有用的工具。你可以将一个大的计算任务拆分成多个小块利用Promise和微任务在每一小块计算完成后让出主线程允许浏览器处理微任务和渲染然后再进行下一块计算。function processHeavyTask(data) { let index 0; function chunk() { const start Date.now(); // 每次处理一小部分数据例如 100 条 while (index data.length Date.now() - start 16) { // 每帧约16ms // ... 处理 data[index] index; } if (index data.length) { // 使用 Promise.resolve().then 将剩余工作安排为微任务 // 这样可以在当前宏任务结束后立即继续但又不会阻塞渲染和交互 Promise.resolve().then(chunk); // 也可以使用 setTimeout(chunk, 0) 安排为宏任务但响应性稍差 } else { console.log(任务完成); } } chunk(); // 启动 }这种模式确保了主线程不会被长时间独占浏览器的渲染和用户交互能够及时得到处理从而保持页面的流畅性。像 React 的 Concurrent Mode并发模式其底层调度思想也与此类似通过中断和恢复渲染任务来保持响应。4.3 在异步流程控制中的应用宏任务和微任务的特性可以帮助我们设计更可控的异步流程。例如有时我们希望某些操作“尽可能快”地执行但又不能阻塞当前同步任务这时微任务就是最佳选择。假设我们有一个日志系统希望在每次状态变更后异步地、但又是“立即地”在下一个宏任务之前将日志批量发送出去。let logQueue []; let isFlushing false; function log(...args) { logQueue.push(args); if (!isFlushing) { isFlushing true; // 使用 queueMicrotask 确保在下一个宏任务前清空队列 queueMicrotask(flushLogs); } } function flushLogs() { while (logQueue.length) { const batch logQueue.splice(0, 10); // 假设批量发送10条 // 模拟发送日志 console.log(发送日志:, batch); // 实际中这里可能是 fetch 或 WebSocket 发送 } isFlushing false; } // 使用 log(用户点击了按钮, {id: 1}); log(API请求开始, {url: /api/data}); // ... 其他同步代码 // 在当前宏任务结束后微任务阶段flushLogs 会被调用批量发送日志。这里使用queueMicrotask而不是setTimeout可以确保日志发送的时机更早、更可预测避免了因宏任务队列中其他任务如动画帧、用户事件的延迟。5. 深度辨析与常见误区即使理解了基本流程一些特殊的场景和 API 仍然可能让人困惑。我们来澄清几个关键点。5.1 requestAnimationFrame它是什么任务requestAnimationFrame是一个用于执行动画的 API它要求浏览器在下次重绘之前调用指定的回调函数。它不属于宏任务也不属于微任务而是位于渲染阶段。在一个事件循环周期中顺序大致是执行一个宏任务。执行所有微任务。浏览器判断是否需要渲染。如果需要则执行执行requestAnimationFrame回调。执行样式计算、布局、绘制等渲染操作。执行requestIdleCallback回调如果存在且有时间。因此rAF的回调执行时机在微任务之后在真正的渲染操作之前。这使它非常适合做动画更新因为你能在浏览器绘制前一帧最新状态。Promise.resolve().then(() console.log(微任务)); setTimeout(() console.log(宏任务 - setTimeout), 0); requestAnimationFrame(() console.log(rAF)); console.log(同步代码); // 典型输出同步代码 - 微任务 - rAF - 宏任务 - setTimeout // 注意rAF 和 setTimeout 的顺序可能因浏览器调度略有差异但 rAF 一定在微任务之后。5.2 微任务的“饿死”问题因为事件循环会持续清空微任务队列如果一个微任务在执行时又向微任务队列添加了新的微任务并且这个过程无限循环下去那么事件循环就会一直停留在清空微任务队列的阶段导致宏任务队列永远得不到执行。这就是“微任务饿死宏任务”。function loopMicrotasks() { Promise.resolve().then(() { console.log(微任务执行中...); loopMicrotasks(); // 递归调用产生新的微任务 }); } loopMicrotasks(); setTimeout(() console.log(这个宏任务永远不会执行), 0);这段代码会导致无限循环的微任务setTimeout的回调永远没有机会执行。在编写代码时要避免在微任务中产生无限循环的微任务。5.3 Node.js 与浏览器的差异Node.js 的事件循环基于 libuv阶段划分比浏览器更复杂包含Timers、I/O Callbacks、Idle/Prepare、Poll、Check、Close Callbacks等多个阶段。setTimeout和setImmediate的执行顺序在有些情况下是不确定的这取决于当前事件循环的上下文。但就微任务而言Node.js 有一个特殊的队列process.nextTick它的优先级高于普通的微任务队列如Promise.then。在每个事件循环阶段切换时Node.js 都会先清空nextTick队列再清空微任务队列。// Node.js 环境 Promise.resolve().then(() console.log(Promise)); process.nextTick(() console.log(nextTick)); console.log(同步); // 输出同步 - nextTick - Promise在跨环境开发时如果对执行顺序有强依赖需要留意这些差异。6. 调试技巧与性能考量理论最终要服务于实践。如何观察和调试任务队列如何编写更高效、更少 Bug 的异步代码6.1 如何观察任务队列的执行现代浏览器的开发者工具是强大的帮手。Performance 面板录制一段操作在 “Main” 线程的可视化图表中你可以看到一个个任务块Task。将鼠标悬停上去可以看到它是哪个函数发起的如setTimeout,click,Promise.then。黄色块代表脚本执行紫色块代表渲染。你可以清晰地看到长任务超过50ms的块通常有红色角标在哪里。Console 面板直接运行包含Promise和setTimeout的代码观察打印顺序是最直接的验证方式。断点调试在setTimeout或Promise.then的回调函数内打上断点查看调用栈可以理解它的调用时机。6.2 编写健壮异步代码的准则警惕“副作用”的时序不要在微任务中执行可能耗时很长的操作因为这会导致后续的宏任务如用户输入、动画被严重延迟。将长任务拆解或交给 Web Worker。理解框架的更新机制像 Vue 的nextTick、React 的setState回调/useEffect它们与任务队列的交互方式。在合适的生命周期或 API 中操作 DOM避免直接依赖不可靠的时序。避免嵌套过深过深的Promise.then或async/await链虽然逻辑清晰但每一层.then都会产生一个微任务。在极端性能敏感的场景下可以考虑扁平化处理。优先使用async/await相比传统的回调地狱和复杂的Promise链async/await让代码更易读错误处理也更方便使用try...catch。虽然底层仍是微任务但可维护性大幅提升。用queueMicrotask进行精细控制当你明确需要一个“在当前任务之后、渲染之前”执行的回调且不希望被当作Promise链的一部分时可以使用这个明确的 API。6.3 一个综合案例优化数据列表渲染假设我们需要渲染一个包含数万条数据的列表直接循环插入 DOM 会导致长任务页面卡顿。不佳的实现function renderList(data) { const container document.getElementById(list); container.innerHTML ; // 清空可能引发一次重排 for (let item of data) { // 长循环阻塞主线程 const div document.createElement(div); div.textContent item.name; container.appendChild(div); // 每次 append 都可能引发重排/重绘 } }优化后的实现利用微任务分片async function renderListOptimized(data) { const container document.getElementById(list); container.innerHTML ; const batchSize 100; // 每批处理100条 for (let i 0; i data.length; i batchSize) { const batch data.slice(i, i batchSize); // 使用 requestAnimationFrame 确保在渲染前更新DOM但这里我们更关注分片 // 使用微任务在每批之间让出控制权 await new Promise(resolve { // 使用 setTimeout 0 也可以但微任务更快。 // 这里用 setTimeout 是为了更清晰地让出控制权给渲染和交互。 setTimeout(() { const fragment document.createDocumentFragment(); for (let item of batch) { const div document.createElement(div); div.textContent item.name; fragment.appendChild(div); } container.appendChild(fragment); // 批量插入减少重排 resolve(); }, 0); // 延迟0ms实际上是放入宏任务队列 }); // 或者使用更现代的方式判断时间片是否用完 // if (Date.now() - startTime 16) { await yieldToMain(); } } } // 一个简单的让出主线程的函数 function yieldToMain() { return new Promise(resolve { setTimeout(resolve, 0); // 或者用 requestAnimationFrame取决于优先级 // requestAnimationFrame(resolve); }); }这个优化版本将长任务拆分成多个短任务宏任务在每个任务之间浏览器有机会处理用户交互、执行微任务和进行渲染从而保持了页面的响应性。选择setTimeout还是requestAnimationFrame取决于你对更新时机的要求前者更快执行后者与屏幕刷新同步更适合动画。宏任务与微任务的机制是 JavaScript 异步编程模型的基石。从最初那个令人困惑的setTimeout延迟问题到如今能够游刃有余地设计复杂的异步数据流和交互理解这套机制让我在调试和性能优化时有了清晰的路线图。它告诉我代码的执行并非所见即所得背后有一个严谨的调度系统在维持秩序。掌握它你就能写出更可预测、更高效的前端代码而不是在出现诡异 Bug 时束手无策。下次当你看到Promise、setTimeout和console.log混在一起时不妨先在脑海里跑一遍事件循环答案往往就清晰了。
