前言

最近重新梳理浏览器事件循环。发现很多文章最终都会落到输出题：

宏任务、微任务、requestAnimationFrame、渲染，到底谁先？老实说，

输出题它适合检查基础概念。但如果只把事件循环背成“宏任务队列 + 微任务队列”，遇到 requestAnimationFrame 和渲染时机就很容易卡住。

我的思路这方面，先看哪些输出是稳定的。再看 timer 和 rAF 为什么不一定谁先，最终结合 Chromium 源码解释背后的原因。

这篇文章参考源码版本固定为：

Chromium: .commit: d096af1c9e98c45c3596e59620622b1a049bfecb

先看一道常见输出题

async function run { console.log;await null，console.log;}console.log;setTimeout => { console.log;},)，Promise.resolve.n => { console.log;})，queueMicrotask => { console.log;})，requestAnimationFrame => { console.log;})，run;console.log，

稳定能确定的输出是：

script startasync startscript endpromisequeueMicrotaskasync end

那后面的 timer 和 rAF 呢？

这就是这道题真正有意思的地方：timer`和``rAF`不一定谁先。

说白了完整输出可能是情况一：

script startasync startscript endpromisequeueMicrotaskasync endrAFtimer

也可能是情况二：

script startasync startscript endpromisequeueMicrotaskasync endtimerrAF

前六行是稳定的，因为它们只涉及当前 script task 和 microtask checkpoint。后两行不稳定，因为它们涉及 timer task 和下一次渲染机会。而浏览器不是每轮事件循环都会渲染。

先给什么时候情况一，什么时候情况二

先把结论放前面：

output situation

common trigger condition

how to understand it |

rAF -> timer

current script task and microtask cleared after browser enters next visual update step;page visible so rAF callback runs during rendering step while browser grabs this frame's rendering opportunity.

Timer -> rAF Current task ends before next frame or just missed a frame;scheduler picks already due timer task first. Page background or low refresh rate or throttled rAF more likely leads browser to execute available timer task first.

microtasks cleared n browser immediately enters rendering step → rAF executed first followed by timer tasks.

microtasks cleared n still no rendering opportunity yet but timer is ready → scheduler may run timer first.

Hence correct answer is not a single deterministic output but description: First six lines stable: Last two lines unstable: rAF / timer relative order depends on wher browser entered rendering opportunity right after microtasks were processed.

请改成简洁版本：

• A microtasks finished → Browser goes into current render update → Executed `rAF` first n any pending timers afterward.
• A microtasks finished → Timer is already ready before render time → Scheduler may run `timer` before `rAF`. 
• The last two lines of this question are refore non-deterministic and cannot be memorized as a single fixed output.
But you must not memorize that “`requestAnimationFrame` always precedes `setTimeout`” – y are different kinds of events . 这也是事件循环容易被误解的地方：

Why 前六行稳定?

整体 script 本身就是一个 task。这个 task 里的同步代码会一直执行到结束，所以先输出：
text
script start async start script end
中间遇到几个异步 API：
* `setTimeout` 注册一个后续 timer task。* `Promise.n` 注册一个微任务。* `queueMicrotask` 注册一个微任务。* `await null` 后面的代码会作为后续微任务执行。* `requestAnimationFrame` 注册下一次渲染前回调。等当前 script task 结束，浏览器会执行微任务检查点，于是依次输出：
text
promise queueMicrotask async end
注意这方面。`timer` 和 `rAF` 谁先，不应该用一句“rAF 一定在 timer 前”来记。`timer` 是后续 timer task，`rAF` 是下一次视觉更新前回调。它们的相对顺序和帧时机、页面状态、调度策略有关。

---

直观模型

我们先不要急着说“宏任务队列”和“微任务队列”，先看浏览器主线程上会发生什么：

• 执行 JS。
• 处理点击、输入、滚动等事件。
• 解析 HTML，建立 DOM。老实说，
• 计算样式和布局。
• 执行 `requestAnimationFrame`。
• 绘制页面。
• 执行 `setTimeout`、网络回调等异步任务。
这些工作大多都要占用主线程。主线程一次只能做一件事，所以浏览器需要一个调度机制：当前这段工作做完后接下来做什么？可以先记住这张简化图： mermaid flowchart TD A --> B B --> C C --> D D --> E{Are microtasks queued?} E -- No --> D E -- Yes --> F{Is it time for visual update?话说回来，} F -- No --> A F -- Yes --> G G --> H H --> A 这张图有三个关键词：

• Task一段普通异步工作。比如整体脚本、定时器回调、事件回调或解析器的一次继续解析。

• MicroTask当前 Task 完成后的收尾，比如 Promise reaction、queueMicroTask 或 await 的后续。

• Rendering Opportunity一次浏览器有机会更新页面的时机，并非每个 Task 后都一定发生。

有了这张图，就能理解为什么 rAF 和 timer 不应该放到同一个简单队列里比较。Timer 等待的是“下一个可运行 Task”，Raf 等待的是“下一次渲染步骤”。

---

Task : 不可随便打断

很多时候页面卡住不是因为浏览器“不想渲染”，而是主线程还没空出来。例如这方面，

javascript box.textContent = 'loading...';while { // 长时间同步计算 }

这里即使修改了 DOM。也不会立刻看到效果，因为当前 JS Task 没结束——浏览器没有机会进入微任务检查点，也没有机会进入渲染更新。

在 Chromium Blink 的调度文档里也能看到这个实现思路。在 Blink 的 Scheduler 文档里可以看到：

cpp // At moment Blink Scheduler treats tasks as an atomic unit...

可以把它理解成 Task 一旦开始，调度器不会从中间把它切开；其实，只有等当前 Task 结束后才会选下一个可运行 Task。

平时写代码时要注意长时间运行的同步操作，例如：

javascript button.addEventListener => { heavyWork;updateDOM，});按理说，

如果 heavyWork 很久。 则使用者输入、动画和渲染都会被拖住。解决思路通常不是换成 Promise，而是把重活拆成多段或放到 Worker。

---

MicroTask : 当前 Task 的收尾

再看 MicroTask。例如的观点是，

javascript console.log;setTimeout => { console.log;},)，Promise.resolve.n => { console.log;})，queueMicrotask => { console.log;})，说起来，console.log;

至于输出为，

text startendpromisemicrotasktimer

说到原因。

1. start,end: 同步代码。

2. Promise.n / queueMicroTask 入微任务队列。

3. setTimeout 入后续 Timer Queue。

4. 当前 Task 完毕后立即清空 MicroTasks。其实，

5. 微任务清完后才轮到下个 Timer 或者 Rendering Opportunity。

再看易错例子的观点是，

javascript Promise.resolve.n => { console.log;queueMicrotask => { console.log;})，});Promise.resolve.n => { console.log;})，setTimeout => { console.log;},)，怎么说呢，

text promise1promise2microtask in promisetimer

此处说明 promise 内追加 MicroTask 会排到当期 Queue 尾部。但仍在本轮 Checkpoint 内完成。不过，若不停追加 MicroTasks 如下面例子。就会阻塞 Rendering:

javascript box.textContent = 'loading...';function loop { queueMicrotask;} loop，按理说，

虽然不是同步死循环。但由于 MicroTask checkpoint 永远无法清空，所以主线程永远不能进入新的 Rendering 或其它 Task。

---

Await 本质是排队时机

下面简单例子展示 await 的排队顺序:

javascript async function foo { console.log;await，console.log;按理说，} Promise.resolve.n => {console.log;})，foo;按理说，Promise.resolve.n=>{console.log;})，

text foo start promise1 foo end promise2

至于关键点，

1. Promise1 入 MicroTask Queue;

2. 调用 foo 输出 'foo start';

3. 当走到 await 时将 'foo end' 入 MicroTask Queue;

4. 再加入 Promise2;

结果顺序为 promise1 → foo end → promise2。

---

DOM 修改并不立即绘制

从举例来看，

javascript box.textContent = 'loading...';box.style.width = '200px';

这里同步修改了 DOM/CSSOM 状态，但并不代表着屏幕已画出。其实，当下 JS Task 未结束，没有进入 MicroTasks 清理。也未达到 Visual Update 时机之前，都无法触发 Render 步骤。下面代码不会在显示 loading 后再做计算：

javascript jsx= box.textContent = 'loading...';let i =，while {}

若想让页面及时刷新，可以将重活推迟至下一轮。如 setTimeout 或 requestAnimationFrame：

javascript jsx= box.textContent = 'loading...';setTimeout=>{ heavyWork;},)，requestAnimationFrame=>{ box.style.transform = 'translateX';})，其实，

---

setTimeout 与 requestAnimationFrame 的区别

setTimeout 是 Timer Task

Blink 源码入口为 dom_timer.cc 简化流程如下:

cpp

int DOMTimer::setTimeout { auto* action = MakeGarbageCollected<ScheduledAction>;return MakeGarbageCollected<DOMTimer>(context,action。base::Milliseconds,true)->timeoutid;} ... if { // ... ... MoveToNewTaskRunner);... } DOMTimer::Fired executes action->Execute;setTimeout 并非马上执行，而投递了一个未来 Timer Task。

requestAnimationFrame 是 渲染前回调

入口在 document.cc 与 scriptedanimationcontroller.cc：

Document::RequestAnimationFrame registers callback in ScriptedAnimationController;Schedule animation if needed. PageAnimator::ServiceScriptedAnimations runs resize/scroll/media query/raf callbacks. This explains *** sometimes raf precedes timers and vice versa.

---

HTML Parsing 在事件循环中的角色

HTML Parser 在 Blink 的 htmldocumentparser.cc 中工作；主要函数 PumpTokenizerIfPossible/PumpTokenizer 按预算解析 HTML。并按需 yield 给其他 high‑priority work，如脚本或样式加载；之后通过 SchedulePumpTokenizer 投递剩余解析至新的 Task。

---

渲染更新到底做了什么

Local Frame View UpdateAllLifecyclePhases 推进 DocumentLifecycle 到 PaintClean；其内部调用 RunStyleAndLayoutLifecyclePhases / RunCompositingInputsLifecyclePhase / RunPrePaintLifecyclePhase / RunPaintLifecyclePhase。在 PageAnimator::ServiceScriptedAnimations 调用中完成 Resize/Scroll/Media Query/raf callbacks，接下来进入样式/layout/pre‑paint/paint/compositing 阶段。

---

从回到最开始来看，如何记忆事件循环？

从规则如下来看，

• The current Task’s synchronous code will run until completion.
• The scheduler never splits a running Task mid‑execution for Rendering.
• A completed Task triggers Microtasks checkpoint immediately afterward.
• The Microtasks queue will be emptied completely—never infinite loops allowed.
• The Rendering step does not occur on every event‑loop iteration—depends on page state &timing strategy.
• requestAnimationFrame is a pre‑render callback—not a normal timed macro‑event like setTimeout.
• Blink’s parser also participates in scheduling on main thread—long parsing can delay scripts &renders alike.

So from opening question’s viewpoint:

The stable part of output is always: