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

理解事件循环：调用栈、任务队列与执行模型

JavaScript 采用单线程模型，同一时刻只能执行一段代码。当代码运行时，函数调用会被压入调用栈（Call Stack），栈顶函数执行完毕后弹出。然而，浏览器环境需要处理网络请求、用户交互和定时器等耗时操作，如果全部同步执行，主线程将被阻塞，导致页面卡死。为了解决这一矛盾，JavaScript 引入了事件循环（Event Loop）机制。同步代码直接在调用栈中执行，而异步操作（如 setTimeout、fetch）会被交给浏览器底层 API 处理，完成后将回调函数放入任务队列。事件循环会不断检查调用栈是否为空，一旦为空，就会从任务队列中取出回调函数推入调用栈执行。这种“同步执行+异步排队+循环检查”的模型，保证了主线程既能高效处理逻辑，又不会被长时间阻塞。开发者可通过在控制台输入 console.log('sync') 观察调用栈瞬间清空的过程，直观理解同步代码的即时性。

宏任务与微任务：来源、特点与核心执行规则

随着异步场景复杂化，任务队列被细分为宏任务（Macrotask）与微任务（Microtask）。宏任务通常由宿主环境发起，包括 setTimeout、setInterval、I/O 操作、UI 渲染等；微任务则由 JavaScript 引擎自身管理，常见于 Promise.then、queueMicrotask、MutationObserver。在一次完整的事件循环中，执行顺序具有严格边界：首先执行当前调用栈中的所有同步代码；同步代码执行完毕后，立即清空微任务队列中的所有微任务；微任务清空后，才会从宏任务队列中取出一个宏任务执行，随后再次检查并清空微任务队列，如此循环。这意味着微任务的优先级始终高于宏任务。例如，在同步代码末尾同时注册 setTimeout 和 Promise.resolve().then()，微任务会优先于宏任务执行。理解这一规则是分析复杂异步逻辑的基础。

用代码验证执行顺序：从简单案例到综合案例

为验证执行顺序，可在浏览器控制台直接运行以下代码：console.log('1'); setTimeout(() => console.log('2'), 0); Promise.resolve().then(() => console.log('3')); console.log('4');。推导过程如下：首先同步执行 console.log('1') 和 console.log('4')，输出 1、4；接着遇到 setTimeout，将其回调放入宏任务队列；遇到 Promise.then，将其回调放入微任务队列；同步代码结束后，事件循环优先清空微任务队列，输出 3；最后执行宏任务，输出 2。若加入嵌套微任务，如 Promise.resolve().then(() => { console.log('A'); Promise.resolve().then(() => console.log('B')); })，微任务队列会在当前循环中持续追加并清空，直到队列为空。开发者可在 Chrome DevTools 的 Console 面板中逐行粘贴运行，或使用 debugger 断点观察调用栈与任务队列的切换，从而彻底掌握异步执行流。

常见误区与开发避坑：为什么顺序会和直觉不同

开发中常因直觉偏差导致异步逻辑出错。首要误区是认为 setTimeout(fn, 0) 会立即执行，实际上它仅表示“尽快”，仍需等待当前同步代码与所有微任务执行完毕。其次，Promise 的回调绝不会抢在同步代码之前，它必须等待当前执行上下文清空。更隐蔽的风险是微任务饥饿：若在微任务中不断递归注册新微任务（如 while 循环内调用 queueMicrotask），微任务队列将永远无法清空，导致宏任务（如 UI 渲染、点击事件）被无限期推迟，页面出现假死。为避免此类问题，应避免在微任务中制造无限递归；对于耗时计算，可拆分为多个 setTimeout 宏任务以让出主线程；使用 requestAnimationFrame 处理动画可确保与浏览器渲染周期同步。通过 Performance 面板录制长任务，可清晰看到微任务堆积导致的帧率下降，从而针对性优化。