各位同学，大家好！我是你们今天的“时间管理大师”，也是那个专门在 React 源码里挖坑填坑的资深专家。
今天咱们不聊组件怎么写，不聊 Hooks 怎么用，咱们聊点更硬核、更底层的东西——React 调度器。
你可能会问：“调度器？那是干嘛的？不就是 React 决定什么时候渲染吗？”
哎，肤浅了。React 作为一个 UI 库，它的核心竞争力之一就是“高性能”。怎么高性能？靠的是它极其精准的时间管理。它就像是一个超级繁忙的机场调度员，手里拿着一张复杂的时刻表（TimerQueue），时刻盯着每一架飞机（任务）的起降时间。
今天，我们就把这层窗户纸捅破，来一场关于 TimerQueue 的深度解剖。我们将亲眼见证一个任务是如何从“天边飞来”变成“落地执行”，又是如何被“无情抛弃”的。准备好了吗？咱们开始！
第一部分：TimerQueue 是个什么鬼？
在 React 的世界里，时间不是线性的，而是离散的。我们称之为 ExpirationTime。这个时间不是毫秒，也不是秒，而是一个巨大的数字（比如 1000000000），代表相对于某个基准点的距离。
React 的调度器为了管理这些任务，手里攥着两个队列：一个叫 taskQueue（未过期队列），一个叫 expiredQueue（过期队列）。
- 未过期队列：那是还没到点儿的“准点航班”。它们整整齐齐地排着队，按照时间戳从小到大排序。就像早高峰的地铁，虽然挤，但大家都有座，或者至少都在等车。
- 过期队列：那是已经超时的“滞留旅客”。这些任务本来该跑的，但可能因为主线程被 JS 占用了，或者优先级太低，导致它们在队列里“烂尾”了。一旦调度器空闲下来，或者主线程终于喘口气，这些过期任务就得被立刻处理。
这就像一个食堂，taskQueue 是“热菜窗口”，expiredQueue 是“冷饭回收站”。
第二部分：插队艺术——insertTimer 的奥秘
当一个任务产生时，它首先会调用 insertTimer。这是 TimerQueue 的入口，也是一场“身份判定”的仪式。
想象一下，你刚拿到一张票（任务对象），票上写着你的起飞时间（expirationTime）。
代码示例 1：insertTimer 的核心逻辑
function insertTimer(task) {
const expirationTime = task.expirationTime;
const currentTime = getCurrentTime();
// 1. 判定生死：这是去热菜窗口，还是去冷饭回收站？
if (expirationTime <= currentTime) {
// 哎呀，这票都过期了！直接扔进过期队列，别耽误事。
// 注意：React 这里可能会对过期队列进行排序，确保最急的先处理。
expiredQueue.push(task);
} else {
// 还没过期！进入未过期队列。
// 这里有个关键点：React 不像普通的堆那样每次都完全重建，
// 而是使用二分查找来找到插入位置，保持数组有序。
insertSortedTimer(task);
}
}看懂了吗？insertTimer 的第一件事就是看时间。如果时间还没到，它就屁颠屁颠地跑进 taskQueue。
但是，taskQueue 是个有序数组，你怎么知道插哪儿？React 这里用的是二分查找。这比遍历整个数组快多了。这就像你在图书馆找书，如果你不看书名直接瞎翻，那是 O(n) 的时间复杂度；如果你知道书是按 A-Z 排的，直接折半查找，那就是 O(log n)。React 就是为了这点性能优化，没少下功夫。
代码示例 2：insertSortedTimer 的二分查找实现
function insertSortedTimer(task) {
let index = 0;
let length = taskQueue.length;
// 二分查找：折半
while (index < length) {
const middleIndex = index + ((length - index) >> 1); // 位运算，防止溢出
const middleTask = taskQueue[middleIndex];
// 如果当前任务的时间 < 中间任务的时间，说明中间任务更晚，往右找
if (task.expirationTime > middleTask.expirationTime) {
index = middleIndex + 1;
} else {
// 否则，中间任务更早，往左找
length = middleIndex;
}
}
// splice 插入：保持队列有序
taskQueue.splice(index, 0, task);
}这段代码写得非常漂亮。没有复杂的指针操作，就是纯粹的数组操作。splice 虽然在数组中间插入元素有点“重”，但因为二分查找的存在，总体效率依然很高。
第三部分：改期风云——updateTimer 的移除与重插
这是 React 调度器里最有趣的一个操作。假设你原本定了一个 10 秒后出发的航班，结果你临时有事，想改签到 20 秒后。
这时候，updateTimer 就粉墨登场了。
React 不会直接修改数组里的某个元素（比如把 index 5 的那个对象的时间属性改了）。为什么？因为数组是有序的。你改了时间，原来的顺序就乱了！
代码示例 3：updateTimer 的“暴力美学”
function updateTimer(task, newExpirationTime) {
// 1. 先把老任务赶走
// 不管它是在过期队列，还是未过期队列，都得先干掉
clearTimer(task);
// 2. 更新时间属性
task.expirationTime = newExpirationTime;
// 3. 重新插队
insertTimer(task);
}看，逻辑非常简单粗暴：移除 -> 修改 -> 插入。
这就像你在餐厅点菜，菜刚端上来（插入），你突然不想吃了（更新），服务员必须先把这道菜撤回厨房（清除），然后重新点一份新的，放回菜单上（插入）。
虽然这看起来增加了两次遍历（一次清除，一次插入），但在 React 的调度逻辑里，这种开销是可以接受的，而且保证了数据的一致性和有序性。
第四部分：无情清场——clearTimer 的精准打击
当你决定取消一个任务时，比如用户点击了“取消预约”，clearTimer 就要开始工作了。
这里有个坑。过期队列和未过期队列里的元素，它们是同一个引用。你不能只清除一个队列里的，忘了另一个。React 的 clearTimer 会同时搜索这两个队列。
代码示例 4：clearTimer 的双重搜索
function clearTimer(task) {
// 在未过期队列里找
const index = taskQueue.indexOf(task);
if (index !== -1) {
taskQueue.splice(index, 1);
}
// 在过期队列里找
const expiredIndex = expiredQueue.indexOf(task);
if (expiredIndex !== -1) {
expiredQueue.splice(expiredIndex, 1);
}
// 清空回调，防止被误调用
task.callback = null;
}这里用到了 indexOf。为什么不用 findIndex 配合箭头函数？因为 indexOf 是原生的，在某些 JavaScript 引擎（尤其是老版本的 V8）里，它的性能通常比自定义的迭代器要快。React 的每一行代码，都是在和浏览器引擎进行博弈。
第五部分：时间到了！——expireTimers 的执行
这是整个调度器的“高潮”部分。当 React 的主线程终于忙完了其他琐事，或者到了该渲染下一帧的时间点，调度器会调用 expireTimers。
它的任务很简单：检查 expiredQueue，把里面的任务全部“吃”掉。
代码示例 5：expireTimers 的执行逻辑
function expireTimers(currentTime) {
// 遍历过期队列，直到队列为空
while (expiredQueue.length > 0) {
// peek: 查看队首元素，但不移除
const earliestExpiredTask = expiredQueue[0];
// 如果队首任务的过期时间还没到（比如 currentTime 变了），那就别处理了
if (earliestExpiredTask.expirationTime > currentTime) {
break;
}
// 移除队首元素
expiredQueue.shift();
// 执行回调！
// 注意：这里没有直接执行，而是通过 requestWork 把它丢进任务队列
// 真正的执行是在 requestAnimationFrame 或 setTimeout 里
if (earliestExpiredTask.callback) {
earliestExpiredTask.callback(earliestExpiredTask.pendingLevel);
}
}
}这里有个细节叫 pendingLevel。React 的任务是有优先级的。过期队列里的任务，虽然时间到了，但可能优先级也不高。pendingLevel 就决定了它什么时候真正执行。如果它是最紧急的，它可能会被立即推入渲染队列；如果它不重要，它可能就先挂起，等下一个空闲周期再说。
第六部分：偷看一眼——peek 的智慧
调度器是怎么知道下一次什么时候醒来的呢？它得知道 taskQueue 里最早的那个任务是什么时候到期的。
peek 函数就是干这个的。
代码示例 6：peek 的实现
function peek() {
// 1. 先看看过期队列里有没有“漏网之鱼”
// 如果有，那肯定得先处理过期任务，不管它优先级高低
if (expiredQueue.length > 0) {
return expiredQueue[0];
}
// 2. 如果没有过期任务，那就看看未过期队列
// 返回队首元素
return taskQueue.length > 0 ? taskQueue[0] : null;
}这个逻辑非常符合直觉：先救火（过期），再按部就班（未过期）。这保证了用户体验，不会因为优先级低而永远等不到执行。
第七部分：深入探讨——为什么不用 Heap（堆）？
讲到这里，肯定有同学要问了：“老师，既然是优先级队列，为什么不用二叉堆（Heap）？堆的插入和删除效率更高啊！”
好问题！这触及到了 React 调度器的核心设计哲学。
React 的调度器不仅仅是一个简单的优先级队列。它需要处理非常复杂的边界情况：
- 任务的取消：在堆里删除一个元素很麻烦，需要重新堆化。
- 任务的更新：修改优先级，在堆里重新插入。
- 时间比较：堆是基于优先级的，而 React 的逻辑是基于“时间”的。
React 选择用两个数组（taskQueue 和 expiredQueue）加上二分查找，是因为：
- 代码简洁性：React 的调度器逻辑非常复杂，如果再引入堆的实现，代码量会爆炸，维护成本极高。
- 局部性原理：在 React 的实际运行中，任务的插入和删除并不是特别频繁。大多数时候，我们只是在
peek（查看）和expire（执行）。对于这些操作，数组的随机访问和二分查找已经足够快了。 - 内存碎片：频繁的堆操作会导致内存分配和回收，这在浏览器环境中可能会引起抖动。数组虽然需要扩容，但操作更稳定。
所以，React 这里的 TimerQueue，实际上是一个定制的、高度优化的、混合数据结构。它用空间换时间，用简单的逻辑换取了极高的稳定性和可维护性。
第八部分：实战演练——一个完整的生命周期
为了让大家彻底明白，我们来模拟一个完整的场景。
假设现在时间是 T0。
步骤 1：插入任务 A
- 任务 A：10秒后到期。
insertTimer(A)：A 的过期时间 > T0，进入taskQueue。taskQueue：[A]
步骤 2：插入任务 B
- 任务 B：5秒后到期。
insertTimer(B)：B 的过期时间 > T0，进入taskQueue，二分查找后插入到 A 前面。taskQueue：[B, A]
步骤 3：插入任务 C
- 任务 C：1秒后到期。
insertTimer(C)：C 的过期时间 > T0，进入taskQueue，插入到 B 前面。taskQueue：[C, B, A]
步骤 4：时间流逝
- 现在时间是
T0 + 2秒。 - 调度器调用
expireTimers。 expiredQueue是空的。peek返回 C。
步骤 5：任务更新
- 我们想改任务 B 的时间为 20秒。
updateTimer(B, 20)。clearTimer(B)：B 从taskQueue中被移除。insertTimer(B)：B 重新进入taskQueue，排在最后。taskQueue：[C, A, B]
步骤 6：再次过期
- 现在时间是
T0 + 12秒。 expireTimers被调用。- 发现 C 和 A 都过期了！
- C 被取出执行。
- A 被取出执行。
- 此时
taskQueue剩下[B]。 expiredQueue依然为空。
步骤 7：取消任务
- 我们决定不执行 B 了。
clearTimer(B)。taskQueue变为[]。
这一套流程下来，是不是感觉 React 像一个精密的瑞士钟表？每一个动作都有迹可循，每一个状态都有明确的定义。
第九部分：状态迁移的“陷阱”与“美学”
在 React 的源码中，TimerQueue 的状态迁移远比上面的伪代码复杂。比如，expiredQueue 在某些极端情况下可能会被“复用”为 taskQueue，以节省内存。
还有一个非常微妙的点：时间溢出。ExpirationTime 是一个 32 位整数。当时间超过一定限度（比如 1 秒后），React 会把它视为“立即过期”。这就像一个倒计时炸弹，一旦时间归零，它就会立刻引爆。
这种设计非常巧妙。它避免了 JavaScript 中 Date.now() 可能产生的精度问题（虽然现在大部分浏览器都支持 10ms 精度了），并提供了一个统一的抽象层。
当我们写 React 应用时，可能根本感觉不到 TimerQueue 的存在。我们只是写了一个 setTimeout 或者一个 useEffect。但正是这些看不见的底层逻辑，支撑起了 React 那丝滑的动画和精准的交互。
第十部分：总结（不，我们不说总结）
好了，同学们。今天我们深入了 React 调度器的腹地，解剖了 TimerQueue 的心脏。
我们看到了 insertTimer 如何像插队一样将任务分类；
我们看到了 updateTimer 如何通过“移除重插”来维持秩序；
我们看到了 expireTimers 如何无情地执行过期任务；
我们甚至探讨了为什么不用堆，而要用数组加二分查找这种看似“笨拙”的方式。
React 的代码库里充满了这种智慧。它不追求最花哨的算法，而是追求最稳定、最可控、最易维护的方案。
下次当你看到 useEffect 的执行时机，或者 React 的并发模式在疯狂切换渲染时，希望你能想起今天讲的这些。你看到的不仅仅是一行代码，而是一个任务在时间轴上奔跑的轨迹。
好了，今天的讲座就到这里。下课！记得回去把你的代码优化一下，别让你的任务在队列里过期了！