JS事件循环：宏任务微任务执行

可视化演示

交互展示JavaScript事件循环机制，剖析调用栈、宏任务队列和微任务队列的执行顺序与优先级。

调用栈机制

大厨站在灶台前，出餐口的小台面只能一层一层地叠盘子：先放上来的盘子在下，后放上来的盘子在上。炒好最上面那盘就端走，显露出下面的盘子继续做。这个“盘子摞”就是 JS 的调用栈（Call Stack）。它决定了 JavaScript 单线程执行的基本面貌——同一时刻，灶台上只有一道菜在炒。

JS 引擎执行代码时也是这样。函数调用函数，就像盘子不断往上叠；引擎一次只能执行栈顶的函数，执行完弹出，再继续下一个。这个结构遵循 LIFO（Last In, First Out，后进先出）。当脚本启动时，全局上下文先入栈；每调用一个函数，就生成一个新“帧”压入栈顶；函数内部如果再调用其他函数，就再压一帧。

调用栈有容量上限，通常在几万到十几万帧之间。如果代码出现无限递归——函数不停调用自己——栈帧会一层层压上去，直到超过上限，浏览器抛出“栈溢出（stack overflow）”错误。这是新手最常遇到的崩溃原因之一。

$$\displaystyle f_1 \rightarrow f_2 \rightarrow f_3 \xRightarrow{\text{执行}} f_3 \rightarrow f_2 \rightarrow f_1$$

1. f1 入栈：第一个函数开始执行，如同一只盘子先放到灶台上。

$$f_1 \uparrow$$

2. f2 压栈：f1 内部调用 f2，新盘子压住 f1。

$$f_2 \uparrow + f_1$$

3. f3 压栈并返回：f2 内部调用 f3，f3 位于栈顶，最先执行完毕并弹出。

$$f_3 \uparrow \Rightarrow f_3 \downarrow$$

4. 逐层出栈：f3 弹出后 f2 继续执行并弹出，最后轮到 f1 弹出。

$$f_2 \downarrow \Rightarrow f_1 \downarrow$$

就像厨师必须先完成最顶层那道菜才能腾出灶台做下面的菜，JS 也必须把当前函数执行完才能回到上一个函数。而排队的订单（异步任务），要等这摞盘子清空后才轮得到。调用栈越小，大厨越轻松；栈一旦爆掉，整家餐厅就得停业重来。

事件循环原理

大厨只有一个灶台，没法同时炒十桌菜。怎么破？餐厅请了一位经理：他不停在厨房和前厅之间巡场，看看灶台有没有空、订单架上有没新单。这位经理，就是事件循环（Event Loop）。他不是厨师，不亲自做菜，只负责“调度”。

事件循环是 JS 引擎深处的调度器。它的日常工作只有一句话：检查调用栈是否为空——为空，就从任务队列里取一个回调放进去执行；不为空，就继续等。这个“检查 → 取任务 → 执行”的过程不断重复，形成一个永不停歇的循环，因此得名“事件循环”。

浏览器环境里有多个任务来源：定时器、网络 I/O、用户交互、DOM 变更等，它们各自排队。事件循环每转一圈，只从宏任务队列取一个任务，然后立刻把微任务队列全部清空，再视情况决定是否进入渲染阶段。注意它不是把队列里的任务一口气执行完，而是“取一个宏任务 → 清空所有微任务 → 再回来取下一个”的节律。

$$\displaystyle \text{Loop} = \underbrace{\text{宏任务}}_{\text{取一个}} \rightarrow \underbrace{\text{微任务}}_{\text{全部清空}} \rightarrow \text{渲染} \rightarrow \cdots$$

1. 判断调用栈是否为空：栈非空时同步代码还在执行，事件循环无法插入任务。

$$\text{stack} = \emptyset \Rightarrow \text{loop 可取任务}$$

2. 取一个宏任务：从宏任务队列队头取一个任务放入调用栈。

$$\text{macro}_{\text{head}} \rightarrow \text{stack}$$

3. 清空微任务队列：当前宏任务结束后，将所有微任务（含新增）执行完。

$$\text{while micro not empty: pop and run}$$

经理就这样日复一日地兜圈子：灶台空了吗？有追加需求吗？有新订单吗？只要有任务，他就永远停不下来。这也是为什么 JS 明明只有一个线程，却能让网络请求、定时器、用户点击“看起来像同时发生”——它们都在迎合这套循环节律。

宏任务队列

前台订单架按先来后到排成长队。新客人的订单签插在队尾，厨师做完一单就撕一单，从不插队。这一摞订单签，就是宏任务队列（MacroTask Queue），遵循先进先出（FIFO）。

宏任务有哪些？定时器 setTimeout、setInterval 的回调；网络 I/O、文件读写的完成回调；用户点击、按键的 UI 事件处理函数。它们都属于“独立任务”——每个宏任务都代表一次全新的执行机会，拥有自己独立的调用栈生命周期。从这个意义上说，每个宏任务都像一位全新的客人，值得一整套完整服务流程。

特别要澄清一个著名误解：setTimeout(fn, 0) 并不是“立即执行”，而是把 fn 作为宏任务放到队列尾部。它最早也要等当前脚本（当前宏任务）执行完、微任务队列清空后，才轮得到执行。所以“延时 0”的实际含义是“尽快排队”，而不是“立刻做”。

$$\displaystyle \text{MacroTask} = \text{定时器} \cup \text{I/O 回调} \cup \text{UI 事件}$$

1. 定时器回调：setTimeout 到期后，回调函数进入宏任务队列。

$$\text{setTimeout}(fn, 0) \Rightarrow fn \in \text{macro}$$

2. I/O 回调：网络请求或文件读写完成后，回调进入宏任务队列。

$$\text{fetch done} \Rightarrow \text{callback} \in \text{macro}$$

3. UI 交互事件：用户点击、按键等事件触发处理函数。

$$\text{click} \Rightarrow \text{handler} \in \text{macro}$$

订单架上的每一张单，都是一桌独立客人。厨师不会为了某个订单的特殊备注打乱整个长队的顺序——宏任务一视同仁，先来先做。理解了这一点，你就不会再问“为什么我明明先写的 setTimeout，却后执行”这种问题了。

微任务队列

客人正吃着，突然喊“甜品马上上！”服务员不能丢下这桌去接待新客，必须先把这桌的追加需求传到厨房。这张“加单”，就是微任务（MicroTask）。它是当前桌子（当前宏任务）的延伸，比任何新订单都优先。

微任务和宏任务最大的区别在于“身份”：宏任务是一次全新的执行机会，微任务则是在当前宏任务收尾时插入的小任务。只要有微任务存在，它们就会在当前宏任务结束后、下一个宏任务开始前，被一次性全部执行完。而且——微任务执行过程中如果又产生了新的微任务，依然要在这一轮全部清空，直到队列变为空。

产生微任务的常见途径有三条：Promise.then / catch / finally 的回调、queueMicrotask(fn) 显式注册的函数、以及 MutationObserver 观察 DOM 变化后的回调。它们都进入同一个微任务队列，共享“优先于宏任务”的待遇。

$$\displaystyle \text{MicroTask} = \text{Promise.then} \cup \text{queueMicrotask} \cup \text{MutationObserver}$$

1. Promise 的回调：Promise 状态变为已决（fulfilled）后，then 回调进入微任务队列。

$$P.\text{resolve} \Rightarrow \text{onFulfilled} \in \text{micro}$$

2. queueMicrotask：显式注册一个微任务函数。

$$\text{queueMicrotask}(fn) \Rightarrow fn \in \text{micro}$$

3. MutationObserver 回调：监听 DOM 变化，变化发生后回调成为微任务。

$$\text{mutation} \Rightarrow \text{observer} \in \text{micro}$$

桌边的追加需求虽然琐碎，却必须优先伺候。这就是为什么在同一个宏任务里，Promise.then 往往比 setTimeout 更早执行——它们根本不在同一条优先级线上，一个是加单，一个是新客。

执行顺序规则

现在把整套流程串起来。经理的巡场规律其实只有一句话：先清空微任务队列，再取一个宏任务。完整规则可以写成：

执行主脚本（视为第一个宏任务）→ 清空微任务队列（含新产生的微任务）→ 取下一个宏任务 → 清空微任务队列 → 如有需要就渲染 → 回到第 3 步。

这套规则里有三个经典的“坑”值得特别注意。第一，微任务执行中产生的新微任务，会在本轮继续清空，不会推迟到下一轮；第二，宏任务执行中产生的新宏任务（比如 setTimeout 里再套 setTimeout），必须等下一轮才执行；第三，正因如此，Promise 天然比 setTimeout 先执行——一个是微任务，一个是宏任务，差距从入队那一刻就注定了。

$$\displaystyle \text{一轮} = \underbrace{\text{一个宏任务}}_{\text{只取一个}} + \underbrace{\text{全部微任务}}_{\text{直到队列为空}}$$

1. 执行一个宏任务：每一轮从宏任务队列队头只取一个任务执行。

$$\text{next} \leftarrow \text{shift}(\text{macro})$$

2. 清空全部微任务：只要微任务队列非空就持续执行，新加进来也要执行。

$$\text{drain}(\text{micro})$$

3. 可选的渲染：有渲染需求时在浏览器帧循环中执行，否则跳过。

$$\text{render} \leftarrow \text{if needed}$$

掌握了“先微后宏、一轮一宏”的节奏，再去看网上各种“这段代码输出顺序是什么”的题目，就像老熟客看菜单一样一目了然。你不需要死记硬背，只需要把自己代入那位巡场的经理，按规则走一遍就知道下一个该轮到谁。

帧渲染协调

餐厅里有位品控经理，每道菜出锅前都会快速检查摆盘、确认温度，再推出餐口。浏览器也有类似角色：它会周期性执行渲染（paint），把最新的样式和布局绘制到屏幕上。而渲染之前，需要一个“最后调整”的窗口，让动画元素换上正确的位置和样式。这个窗口，就是 requestAnimationFrame（rAF）。

rAF 的特殊之处在于：它既不是宏任务，也不是微任务，而是独立于两者之外、在浏览器渲染新一帧之前统一执行的“帧任务”。它每帧最多调用一次，并且严格跟随屏幕刷新率（通常是 60Hz）。相比之下，setTimeout 回调既不保证时间精确，也不关心屏幕刷新节奏，后台标签页里还会被节流甚至停掉。

用 rAF 做动画有三点优势：第一，跟随刷新率，避免掉帧；第二，页面切到后台时自动暂停，节省资源；第三，回调在渲染前触发，能保证样式调整不会错过当前帧的绘制时机。

$$\displaystyle \text{Frame} = \text{MacroTask} + \text{MicroTask} + \text{rAF} + \text{渲染}$$

1. 宏任务与微任务更新状态：常规异步回调在一帧中先执行，完成数据更新。

$$\text{macro} + \text{micro} \Rightarrow \text{更新数据}$$

2. rAF 回调调整布局：渲染前最后一次调整元素位置与样式。

$$\text{rAF callbacks} \Rightarrow \text{调整位置}$$

3. 浏览器渲染绘制：把计算结果绘制为屏幕像素，展示给用户。

$$\text{paint} \Rightarrow \text{呈现给用户}$$

动画要用 rAF 而不是 setTimeout，就是因为品控经理会在每道菜“出锅上桌前”最后把关。如果你用 setTimeout 做动画，回调可能落在帧与帧之间，出现画面抖动——菜早就炒好了，却没赶上品控检查的窗口。

异步性能陷阱

厨房最容易出乱子的情况有三种：顺序搞反、灶台被占死、赶单导致撒汤。异步代码也一样，最常见的三个性能陷阱是：执行顺序混淆、渲染阻塞和微任务风暴。

执行顺序混淆源于对“先写先执行”的直觉。交互事件和定时器同时触发时，新手常以为代码书写顺序就是执行顺序。真正的钥匙是“先微后宏”：把所有回调按宏任务与微任务分类，心里就有一张准确的运行时间表。渲染阻塞更常见：一段耗时超过 16.6ms 的同步代码，会让浏览器来不及绘制下一帧，用户感受到的便是卡顿掉帧。方案是拆帧——把一个大任务切成多个小宏任务，让渲染有机会插队。

微任务风暴最隐蔽也最危险：如果微任务不断创建新的微任务（比如不收敛的递归 then），事件循环会永远停留在微任务阶段，宏任务队列被“饿死”，页面将无法响应用户操作。记住一条底线：微任务里不要写没有终止条件的递归。

$$\displaystyle \text{帧预算} = \frac{1000\text{ms}}{60\text{fps}} \approx 16.6\text{ms}$$

1. 帧预算定义：每秒显示 60 帧，则每帧只能占用约 16.6 毫秒。

$$\text{budget} = 1000 / 60$$

2. 超预算的后果：任务挤占渲染时间，页面因此掉帧卡顿。

$$\text{time} > 16.6\text{ms} \Rightarrow \text{jank}$$

3. 拆帧优化：把长任务切分成多个短任务，让每段都不超过预算。

$$\text{long} \rightarrow \sum \text{chunks} \leq \text{budget}$$

好的厨房，井井有条：经理调度有方、灶台不堵、品控准时。好的异步代码也一样——任务分得清主次，长任务拆得开，微任务收得住。你的页面就会像流水席一样顺畅，而不是像高峰期厨房那样兵荒马乱。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""用 Python 模拟 JS 事件循环:宏任务与微任务调度"""from collections import deque  def simulate_event_loop():    # 宏任务队列(新客订单)    macro = deque()    # 微任务队列(当前桌加单)    micro = deque()    log = []     def add_macro(name):        macro.append(name)     def add_micro(name):        micro.append(name)     # 主脚本开始:注册一批异步任务    add_micro("Promise.then #1")    add_micro("Promise.then #2")    add_macro("setTimeout 回调")    add_macro("fetch 回调")    add_macro("click 回调")     while macro or micro:        # 1. 每次取宏任务前,先清空整个微任务队列        while micro:            task = micro.popleft()            log.append("[微任务] " + task)            # 模拟微任务产生新微任务(本轮必须继续清空)            if task == "Promise.then #1":                add_micro("queueMicrotask")        if not macro:            break        # 2. 宏任务先进先出,一次只取一个        task = macro.popleft()        log.append("[宏任务] " + task)        # 宏任务可能产生新的微任务        if task == "setTimeout 回调":            add_micro("setTimeout 产生 then")     return log  if __name__ == "__main__":    for line in simulate_event_loop():        print(line)

1. while macro or micro:只要两个队列还存在任务，事件循环就继续转圈。
2. while micro:每次取宏任务之前，先一口气清空所有微任务，这是事件循环的第一原则。
3. task = micro.popleft()微任务按先进先出顺序执行，和宏任务一样都讲究先来后到。
4. if task == "Promise.then #1": add_micro("queueMicrotask")模拟微任务执行中产生新微任务，证明新微任务本轮也会被清空。
5. task = macro.popleft()宏任务一次只取一个，取完立刻回头检查微任务队列。
6. if task == "setTimeout 回调": add_micro("setTimeout 产生 then")模拟宏任务产生微任务，展示这个微任务会在下一个宏任务前被优先执行。

常见误区

面试题