各位前端界的“老司机”们，大家下午好！
今天咱们不聊那些花里胡哨的 Hooks，也不聊组件树怎么渲染，咱们来聊聊 React 背后的那个“大管家”——调度器。
大家都知道，React 18 带来了并发模式，就像给这台老旧的计算机换上了一颗高性能的 CPU。并发模式的核心是什么？是时间切片。React 不再是一次性把所有活儿干完，而是像那个强迫症晚期的管家一样，把任务切成一小块一小块，见缝插针地执行。
在这个“见缝插针”的过程中，有一个非常不起眼但又至关重要的函数，它负责在每一轮工作循环中，去检查那些“时间到了”的任务，然后把它们推到执行队列里。这个函数，就是 advanceTimers。
今天，咱们就剥开 React 的外衣，像解剖一只青蛙一样，把这个函数放在显微镜下，好好看看它在 workLoop 里到底经历了什么，以及它到底有多“重”。
第一部分：Work Loop —— 调度器的引擎
在讲 advanceTimers 之前，咱们得先搞清楚 workLoop 是个啥。想象一下，你是一个餐厅的经理。餐厅里有很多桌客人（任务）。有的客人点了“红烧肉”（高优先级），有的点了“白开水”（低优先级）。
workLoop 就是你那个拿着大喇叭的指挥系统。你不能把红烧肉一次性端给所有客人，因为那样厨房会炸锅。所以，你只能端一盘，看一眼时间，如果时间不够了，或者厨房忙不过来了，你就喊停，等下一轮再来。
在 React 的调度器源码里，workLoop 通常是这样的结构（伪代码版）：
// 模拟 React 的调度器环境
let currentTime = 0;
const timers = new Map(); // 存储所有的 setTimeout/setInterval 任务
function workLoop(deadline) {
// 每一轮循环，首先更新当前时间
currentTime = currentTime + 1; // 简化版：每帧加1ms
// 核心循环：只要还有时间，或者还有任务，就干活
while (deadline.timeRemaining() > 0 || hasScheduledCallback()) {
// 1. 执行高优先级任务（比如用户点击了按钮）
// performHighPriorityWork();
// 2. 【关键点】在这里，我们需要检查那些“延迟任务”
// 如果不检查，setTimeout 的回调就会在下一帧才能执行，
// 导致页面卡顿，或者逻辑错乱。
advanceTimers();
// 3. 执行低优先级任务（比如组件更新）
// performLowPriorityWork();
}
}看到了吗？advanceTimers 就夹在高优先级工作和低优先级工作中间。它就像是那个在厨房门口探头探脑的服务员，时刻盯着墙上的挂钟。
第二部分：Timers —— 时间的小偷
在 React 的调度器里，setTimeout 和 setInterval 这些浏览器原生的 API，并不是直接生效的。React 为了控制渲染节奏，自己搞了一个 Scheduler 包，接管了这些 API。
当你调用 setTimeout(callback, 500) 时，React 并不是把回调扔给浏览器就不管了。React 会把它存起来，记录下这个回调应该在什么时候执行。这个时间点，我们称之为 expirationTime。
想象一下，你的浏览器就像一条懒洋洋的猫。你给它下了一个 500ms 的单，说“500ms 后叫醒我”。猫会乖乖等着吗？大概率不会。猫可能睡过去了，或者去抓老鼠了。
所以，React 必须自己“看表”。这就是 advanceTimers 的存在意义。
第三部分：advanceTimers 的真面目
现在，让我们把目光聚焦到 advanceTimers 函数本身。它的代码不长，但逻辑非常精妙。让我们来看看它的源码逻辑（基于 React 18 的简化实现）：
function advanceTimers(currentTime, deadline) {
// 这里的 timersMap 是调度器内部维护的一个 Map 结构
// key 是回调函数，value 是该回调对应的过期时间
let callbacks = timersMap.get(currentTime);
// 如果当前时间正好有任务到期
if (callbacks !== undefined) {
// 把这个时间点对应的所有回调拿出来
// 注意：这里使用了一个 Set 来避免重复添加
let firstCallback = callbacks.first;
let lastCallback = callbacks.last;
let next = null;
// 开始遍历这一波到期的任务
// 这是一个典型的链表遍历操作
while (firstCallback !== null) {
// 1. 标记这个回调为“已过期”或者“即将执行”
firstCallback.expired = true;
// 2. 把它从当前时间的队列里移除
if (firstCallback === lastCallback) {
// 如果是最后一个，就把这个时间点的队列置空
timersMap.delete(currentTime);
} else {
// 如果不是最后一个，更新指针，让下一个节点变成 last
next = firstCallback.next;
callbacks.first = next;
}
// 3. 【重排】把回调推入到“待执行队列”
// 注意：这里没有直接执行，而是放入了任务队列
// 这样可以保证即使回调里又 setTimeout 了，也能被调度器捕获
pushCallback(firstCallback);
// 4. 移动到下一个节点
firstCallback = next;
}
}
// 还有一个特殊的逻辑：requestAnimationFrame
// 如果时间还没到，但距离下一帧刷新时间很近了，也触发一下
if (currentTime >= lastRenderedDeadline) {
// ...处理 requestAnimationFrame 的逻辑
}
}这段代码虽然短，但信息量巨大。咱们来拆解一下：
- Map 的 Key 是时间：React 的调度器维护了一个
timersMap，它的 Key 是时间戳。这就好比挂了一个巨大的日历牌，上面写着“10:00:00 放烟花”，“10:05:00 发短信”。 - 链表结构：在同一个时间点，可能会有多个
setTimeout到期了。React 使用了一个双向链表（或者单向链表，取决于版本）来存储这些回调。这比数组更高效，因为不需要每次都重排数组。 - 从 Map 到 Queue 的转移：
advanceTimers的核心动作，就是把“已经到期的任务”从“时间日历”上摘下来，扔进“执行队列”。这就是所谓的“重排”或“调度”。
第四部分：触发时机 —— 为什么是每一轮？
这是大家最容易困惑的地方。为什么要在 workLoop 的每一轮迭代都调用 advanceTimers？为什么不在主线程空闲的时候调用？为什么不在每次 setTimeout 到期的时候调用？
原因很简单：浏览器不可靠，React 必须主动出击。
场景模拟：
假设你有一个高优先级的任务（比如用户输入），React 正在执行它。此时，requestIdleCallback 回调还没被浏览器触发（因为浏览器还在忙着处理你的输入事件，主线程很忙）。
如果 advanceTimers 不在 workLoop 里，会发生什么？
setTimeout在 100ms 后到期了。- 浏览器的主线程正在处理你的高优先级输入，根本没空去检查时间。
- 那个 100ms 后的回调被无限期地推迟。
- 用户感觉页面卡死了，或者逻辑跑飞了。
但是，如果 advanceTimers 在 workLoop 里：
workLoop开始运行。- 执行完高优先级输入。
advanceTimers被调用。- 它检查时间，发现 100ms 到期了。
- 它把回调推入队列。
workLoop继续运行，或者调度器安排时间执行这个回调。
所以，advanceTimers 是一个“守门员”。无论主线程在忙什么，它都在那儿，时刻盯着表，防止时间被浪费。
第五部分：深入剖析开销 —— 到底有多贵？
既然 advanceTimers 在每一轮迭代都跑，那它会不会成为性能瓶颈？这就是咱们今天要探讨的“开销”问题。
1. 时间复杂度：O(N)
advanceTimers 的工作逻辑是：遍历 timersMap -> 检查过期时间 -> 移动节点。
如果 timersMap 里只有 1 个定时器，那它跑得飞快，跟没跑一样。但如果你的应用里，开发者滥用 setTimeout，成千上万个定时器同时存在呢？
假设你有 10000 个定时器，其中 50 个刚好在当前时间点到期。advanceTimers 就得遍历这 10000 个键值对，虽然大部分是不匹配的，但Map 的查找和遍历本身也是有成本的。
更糟糕的是，如果这 10000 个定时器都在 100ms 内陆续到期，那么在接下来的 100ms 里，advanceTimers 会被调用无数次（每一帧都调用）。这意味着它要重复遍历这 10000 个键值对。这可是实打实的 CPU 消耗！
2. 内存开销
为了实现高效的重排，React 使用了链表结构来存储回调。这意味着每个回调节点除了存储函数本身，还需要额外的指针（next, prev）来维护链表。如果回调数量巨大，内存开销也会随之增加。
3. 与渲染工作的对比
在 workLoop 中，advanceTimers 的开销通常被视为“低优先级”的维护工作。渲染工作（DOM 更新、Commit 阶段）是昂贵的（因为涉及到浏览器重绘重排）。相比之下，遍历一个 Map 的开销是可以接受的。
但是，如果 advanceTimers 的开销过大，就会挤占渲染的时间。比如在一个极其繁忙的页面（每秒 60 帧都在跑任务），大量的定时器回调可能导致调度器把所有 CPU 时间都花在了管理定时器上，而忘了渲染页面，导致页面掉帧。
代码示例：性能瓶颈演示
// 这是一个夸张的例子，用来演示开销
function simulateHeavyTimers() {
const timersMap = new Map();
const callbacks = [];
// 1. 模拟注册 10000 个定时器
for (let i = 0; i < 10000; i++) {
// 每隔 10ms 到期一个
const time = Date.now() + (i % 10) * 10;
// ... 注册逻辑省略 ...
}
// 2. 模拟 advanceTimers 的执行
function advanceTimers(currentTime) {
// 这里是性能敏感区
// 遍历 Map 的 Key
for (const timeKey of timersMap.keys()) {
// 假设这里有个复杂的判断逻辑
if (timeKey <= currentTime) {
// ... 触发回调
}
}
}
// 模拟每一帧调用
let frameCount = 0;
function workLoop() {
frameCount++;
const currentTime = Date.now();
advanceTimers(currentTime);
if (frameCount < 100) {
requestAnimationFrame(workLoop);
}
}
workLoop();
}在这个例子中，timersMap.keys() 的遍历在每一帧都会发生。如果 Map 很大，这会非常消耗性能。
React 的优化策略
React 作为一个成熟的框架，肯定意识到了这个问题。它采取了一些优化策略：
- 批量处理：
advanceTimers不会一次性触发所有到期的回调。它可能会一次触发一部分，然后让出控制权，让出workLoop去执行其他任务。这叫“协作式多任务处理”。 - 时间切片：React 限制了
workLoop每次执行的时间。这意味着即使有大量定时器到期，advanceTimers也不会一次性把它们全部处理完，而是分摊到每一帧中。
第六部分：expiredTime 的玄机
在 React 的源码中，还有一个概念叫 expiredTime。这是 advanceTimers 检查的一个重要标准。
当一个任务被调度时，React 会给它分配一个 expirationTime。这个时间通常基于任务的优先级。
- 高优先级任务：
expirationTime很近（比如 50ms 后）。 - 低优先级任务：
expirationTime很远（比如 5000ms 后）。
advanceTimers 在检查时，不仅仅看 currentTime，还会看任务的 expirationTime。
// 源码逻辑简化版
function advanceTimers(currentTime, expirationTime) {
let callbacks = timersMap.get(currentTime);
if (callbacks) {
// ...
while (firstCallback !== null) {
// 关键判断：不仅时间到了，而且任务的优先级还没过期
if (firstCallback.expirationTime > expirationTime) {
// 只有当任务还没被标记为“过期”时，才真正执行
pushCallback(firstCallback);
}
// ...
}
}
}这里有一个很有意思的逻辑：“过期”并不等于“立即执行”。
如果一个定时器已经到期了，但它的优先级太低（比如一个很久没用的组件里的定时器），React 可能会暂时忽略它，把它标记为 expired，等到主线程有空了，或者有高优先级任务插入时，再处理它。
这就是所谓的“延迟任务重排”。React 并不急着把所有到期的任务都塞进队列，而是根据整体负载情况，进行动态的调度。
第七部分：实战中的影响
了解了 advanceTimers 的原理和开销，对我们写代码有什么影响呢？
1. 避免滥用 setTimeout
如果你在 React 组件中频繁使用 setTimeout 来做轮询或者动画，你实际上是在给 React 的调度器增加负担。虽然现代浏览器的 GC 和调度器已经很强了，但如果你在 useEffect 里写了一堆 setTimeout，或者在一个高频更新的列表里用 setTimeout，可能会导致 advanceTimers 的开销过大。
建议：对于动画和定时任务，尽量使用 requestAnimationFrame 或 CSS 动画。对于需要精确时间控制但频率不高的任务，可以考虑使用 setTimeout，但要控制数量。
2. 理解“调度”而非“执行”
advanceTimers 只是把回调推入队列。真正的执行是在 workLoop 的后面阶段。这意味着，如果你在 setTimeout 的回调里执行了 setState，这个更新会被加入到 React 的更新队列中。
React 的调度器会决定是立即更新（如果优先级够高），还是推迟到下一帧。这解释了为什么有时候你会发现，你写的 setTimeout 触发的更新，比预期的要晚一点点。
3. 并发模式的坑
在 React 18 的并发模式下，advanceTimers 的行为变得更加复杂。因为 React 可能会在任何时刻中断当前的 workLoop，去处理一个高优先级的更新。
这意味着，正在被 advanceTimers 遍历的定时器回调队列，可能会被临时挂起，或者被重新排序。这对于开发者来说是一个“黑盒”，你需要知道，你的 setTimeout 回调不一定严格按照你设定的延迟时间执行，而是取决于 React 的调度策略。
第八部分：总结与展望
好了，各位，咱们今天把 advanceTimers 这个“隐形的守护者”给扒了个底朝天。
回顾一下：
- 位置：它在
workLoop的每一轮迭代中运行，确保时间不流逝。 - 作用：检查
timersMap，把到期的回调从“时间日历”移到“执行队列”，完成延迟任务的重排。 - 开销：虽然时间复杂度是 O(N)，但在 React 的调度策略下，这个开销是可以接受的。它通过时间切片和协作式调度，避免了单帧卡顿。
advanceTimers 是 React 并发模式能够流畅运行的关键一环。它就像一个不知疲倦的图书管理员，在书架（时间）和阅读室（执行队列）之间来回搬运书籍（回调函数），确保每一本书都能在它该出现的时候出现。
理解了它，你就理解了 React 为什么能一边处理复杂的 UI 更新，一边还能保证 setTimeout 的回调不会迟到。
最后，我想说的是，编程不仅仅是写代码，更是理解系统。当你看到控制台里那些纷繁复杂的调度日志时，不要害怕。想想那个在 workLoop 里不知疲倦跑着的 advanceTimers，你可能会会心一笑：哦，原来它还在那儿忙着呢。
这就是技术的魅力，枯燥的代码背后，藏着精密的逻辑和优雅的设计。希望大家在未来的开发中，能写出既让用户爽，又让调度器舒服的代码！
好了，今天的讲座就到这里。下课！