各位同学，把手里的咖啡放下，把手机静音，把那个正在疯狂刷新的 React 开发者论坛关掉。今天咱们不讲那些花里胡哨的 Hooks，也不聊 TypeScript 的类型体操，咱们来聊聊 React 源码里最硬核、最像“幕后黑手”的那个模块——Scheduler。
你可能会问：“Scheduler 是干嘛的？不就是 setTimeout 的高级封装吗？”
错！大错特错！setTimeout 那是个暴躁的老头，它说“三秒后执行”，你就得乖乖等三秒，哪怕你还有一秒钟就能把那个该死的 alert 关掉。而 React Scheduler 是个精明的 HR 经理，它手里拿着一把尺子，时刻盯着时间，告诉你：“嘿，哥们，你的活儿干完了，现在把键盘让给浏览器渲染引擎，你自己歇会儿。”
为了实现这个“精明的 HR 经理”，React 选用了最小堆。这玩意儿是计算机科学里的瑞士军刀，专门用来处理“谁最急”这种问题。
今天，我们就来扒开 Scheduler 的内裤，看看这个基于最小堆的任务队列到底是怎么运作的。
第一部分：为什么我们需要 Scheduler？（浏览器与 React 的爱恨情仇）
在讲堆之前，咱们得先理解背景。想象一下，你是一个 React 组件。你正在渲染一个包含 10,000 个列表项的页面。
如果你是个暴力的家伙，你会写一个 forEach 循环，把这 10,000 个元素一次性都渲染出来。结果是什么？浏览器主线程被你堵死了 500 毫秒。这时候，用户想点个按钮，鼠标悬停一下，系统都毫无反应。用户会想：“这破网页是死机了吗？”然后愤怒地关掉标签页。
React 不想当那个暴力的家伙。React 是个讲究“用户体验”的艺术家。它想把这 10,000 个列表项切成 50 个一组，每一组渲染 10 毫秒，然后告诉浏览器：“老板，这 10 毫秒干完了，您老先去画个图，我去喝口水。”这就是时间切片的核心思想。
但是，问题来了。怎么知道什么时候该“喝口水”？怎么知道哪组数据是最急迫的？
这时候，Scheduler 登场了。它的核心任务就是维护一个任务队列，并且这个队列必须能实时告诉 React：现在哪个任务最重要，哪个任务已经过期该扔了。
如果用普通的数组 Array 来存任务，每次要找“最急迫”的任务，你就得遍历一遍数组，时间复杂度是 $O(N)$。如果任务多了（比如成千上万个），这就像是在一个一百万人的操场上找那个跑得最快的人，效率低得感人。
于是，最小堆来了。它能在 $O(log N)$ 的时间内完成插入和删除操作。这就是为什么 React 选了它。
第二部分：最小堆——食堂排队的智慧
为了让你深刻理解最小堆，咱们来个场景模拟。
假设有一个食堂，大家都想吃饭，但是只有一个窗口。食堂大妈（也就是 CPU）一次只能给一个人打饭。
普通队列（FIFO）： 谁先来谁先吃。不管你饿得要死，还是你只是想顺便吃个饭，你都得排在后面。这叫“先来后到”，公平是公平，但效率低。
最小堆（Priority Queue）： 每个人进门的时候，都要先报一下自己的“饥饿指数”或者“截止时间”。
- 小明说：“我饿死了，还有 1 分钟就要饿晕了！”（优先级极高）
- 小红说：“我有点饿，还有 10 分钟。”（优先级中等）
- 小刚说：“我刚来，但我只是想玩玩。”（优先级极低）
最小堆会把那个“饿得最惨（最小值）”的人放在最前面。一旦小明插队排到了最前面，大妈就得先给他打饭。这叫“急事优先”。
在 React 里，每个任务都有一个 expirationTime（过期时间）。时间越早，越紧迫。Scheduler 的任务队列，就是这样一个“饥饿指数”最小堆。
堆的底层结构：完全二叉树
堆不是树，它是一种特殊的树。为了在计算机内存里存下它，我们用数组来模拟。
想象一个完全二叉树：
[10]
/
[15] [20]
/ /
[30] [25] [35] [40]在数组里，它长这样：
[10, 15, 20, 30, 25, 35, 40]
注意这个规律：
- 索引
i的左孩子是2 * i + 1。 - 索引
i的右孩子是2 * i + 2。 - 索引
i的父节点是Math.floor((i - 1) / 2)。
这就是堆的数学魔法。为什么我们要用数组？因为数组在内存里是连续的，CPU 访问起来飞快，而且不需要像链表那样维护指针，省空间，省时间。
第三部分：代码实战——手写一个 Scheduler
光说不练假把式。咱们不直接看 React 源码（那代码像天书一样），咱们自己写一个简化版的 React Scheduler。
1. 定义任务结构
首先，得有个任务对象。它得知道自己是谁，什么时候到期，以及它的回调函数。
// 任务对象
class Task {
constructor(callback, expirationTime) {
this.callback = callback; // 要执行的任务函数
this.expirationTime = expirationTime; // 过期时间（毫秒）
this.sortIndex = expirationTime; // 用于排序的索引，直接等于过期时间
}
}2. 最小堆的核心实现
这是重头戏。我们需要两个核心方法：bubbleUp（上浮）和 siftDown（下沉）。
为什么要上浮？
当你往堆里插入了一个新的任务，这个任务可能比它的父节点更“急迫”（过期时间更小）。为了让堆保持“最小值在顶部”的特性，你得把它往上推，直到它碰到一个比它大（或相等）的祖宗。
为什么要下沉？
当你把堆顶（最急迫的任务）拿出来执行了，堆就空了。为了填补这个空缺，你得把堆里最后一个元素搬到堆顶，然后看看它是不是比它的两个儿子都“急迫”。如果它比某个儿子急，就得往下沉，直到它比两个儿子都大（或者它是个叶子节点）。
class MinHeap {
constructor() {
this.tasks = []; // 存任务的数组
}
// 比较函数：谁的时间早，谁就小
compare(a, b) {
return a.expirationTime - b.expirationTime;
}
// 插入任务
push(task) {
this.tasks.push(task);
this.bubbleUp(this.tasks.length - 1);
}
// 提取最急迫的任务（堆顶）
pop() {
const first = this.tasks[0];
const end = this.tasks.pop();
// 如果堆里还有任务，把最后一个任务放到堆顶，然后开始下沉
if (this.tasks.length > 0) {
this.tasks[0] = end;
this.siftDown(0);
}
return first;
}
// 上浮逻辑：从后往前，找到合适的位置
bubbleUp(n) {
const task = this.tasks[n];
while (n > 0) {
const parentIndex = Math.floor((n - 1) / 2);
const parent = this.tasks[parentIndex];
// 如果当前任务比父节点“更急”（时间更小），交换
if (this.compare(task, parent) < 0) {
this.tasks[parentIndex] = task;
this.tasks[n] = parent;
n = parentIndex;
} else {
break; // 找到家了，停！
}
}
}
// 下沉逻辑：从前往后，找到合适的位置
siftDown(n) {
const length = this.tasks.length;
const task = this.tasks[n];
while (true) {
const childIndex1 = n * 2 + 1; // 左孩子
const childIndex2 = n * 2 + 2; // 右孩子
let swapIndex = null;
// 找出两个儿子中“更急”的那个
if (childIndex1 < length) {
const child1 = this.tasks[childIndex1];
if (this.compare(child1, task) < 0) {
swapIndex = childIndex1;
}
}
if (childIndex2 < length) {
const child2 = this.tasks[childIndex2];
if (
(swapIndex === null && this.compare(child2, task) < 0) ||
(swapIndex !== null && this.compare(child2, this.tasks[swapIndex]) < 0)
) {
swapIndex = childIndex2;
}
}
// 如果找到了比当前任务更急的孩子，交换
if (swapIndex !== null) {
this.tasks[n] = this.tasks[swapIndex];
this.tasks[swapIndex] = task;
n = swapIndex;
} else {
break; // 安全了，停！
}
}
}
}看懂了吗？这就是最小堆的灵魂。bubbleUp 是为了维护堆的“有序性”，siftDown 是为了填补空缺。整个过程的时间复杂度都是 $O(log N)$。
第四部分：React Scheduler 的调度循环
光有堆还不够，React 还需要一个“调度循环”来不断从堆里掏任务出来执行。这就是 requestHostCallback 和 performConcurrentWorkOnRoot 的故事。
1. 时间切片的魔法
React Scheduler 不是一个同步函数，它是一个“事件驱动”的循环。它不会一次性把所有任务都干完，它会干一会儿，就停下来看看时间。
let currentTask = null;
let startTime = 0;
let deadline = 0;
function scheduleCallback(expirationTime, callback) {
// 1. 创建任务对象
const task = new Task(callback, expirationTime);
// 2. 把任务扔进最小堆
heap.push(task);
// 3. 触发调度（稍后讲）
requestHostCallback();
}
function requestHostCallback() {
// 这里的逻辑稍微简化了，实际上 React 会根据环境决定用 setTimeout 还是 MessageChannel
// 但核心思想是：告诉浏览器“嘿，我有点活儿要干，但我可能干不完，干不完你叫我。”
setTimeout(tick, 0);
}
function tick() {
// 计算截止时间
deadline = performance.now() + 5000; // 假设给 5ms 的时间片
// 开始干活
performWorkUntilDeadline();
}
function performWorkUntilDeadline() {
// 如果堆是空的，那就真的没事干了，让浏览器喘口气
if (heap.tasks.length === 0) {
return;
}
// 开始循环
while (true) {
// 1. 检查当前时间是否已经超过了任务的截止时间
if (performance.now() >= deadline) {
// 时间到了！必须让出控制权给浏览器渲染 UI
// React 会在这里重新调用 requestHostCallback
requestHostCallback();
return;
}
// 2. 从堆顶取出最急迫的任务
const task = heap.pop();
if (!task) {
// 堆空了
return;
}
// 3. 执行任务
currentTask = task;
startTime = performance.now();
try {
// 执行 React 的渲染逻辑
task.callback();
} catch (error) {
// 出错了，处理错误
} finally {
currentTask = null;
// 4. 关键判断：任务执行完了吗？
// 如果执行完，继续循环；如果没执行完，说明任务太重了，或者时间到了，跳出循环
// 计算任务执行花了多久
const timeElapsed = performance.now() - startTime;
// 如果任务还没执行完，且时间还没到，继续执行
if (timeElapsed < task.expirationTime - deadline) {
// 这是一个重要的优化：如果任务还没完，但还没超时，说明这个任务比较轻，可以继续在当前帧内执行完
heap.push(task); // 把任务放回堆里（注意：它现在的排序位置可能变了，但堆会自动调整）
requestHostCallback();
return;
}
}
}
}这段代码是 Scheduler 的心脏。
你看那个 while (true) 循环。React 就像是一个不知疲倦的打工人，疯狂地从堆里拿任务，执行，检查时间。一旦 deadline 到了，它就立刻停止，把控制权交还给浏览器。
这就是为什么 React 能保持页面不卡顿的原因。它把一个巨大的、可能耗时 100ms 的渲染任务，拆解成了几十个 5ms 的小任务。在每一个小任务之间，浏览器都有机会去重绘屏幕，去响应用户的点击。
第五部分：优先级提升——动态插入的艺术
这是 React 18 引入并发模式后的一个神级特性。
假设你正在执行一个低优先级的任务（比如计算一些统计数据），突然来了一个高优先级的任务（比如用户点击了“提交表单”或“更新状态”）。
这时候，普通的队列会怎么做？它会等低优先级任务干完再说。那用户点击表单的反馈就会延迟 100ms，体验极差。
有了最小堆，React 可以动态插入。
// 用户点击了按钮，触发了一个高优先级任务
function handleUserClick() {
// 1. 创建高优先级任务，过期时间设为 100ms
const highPriorityTask = new Task(() => {
console.log("提交表单！");
}, 100); // 假设现在时间 0，100ms 后过期
// 2. 直接把这个任务推入堆中
heap.push(highPriorityTask);
// 3. 触发调度（如果当前没有在跑的话）
if (!isRunning) {
requestHostCallback();
}
}当 requestHostCallback 再次运行时，它会去堆顶看一眼。堆顶是谁？
- 如果是刚才那个低优先级任务（比如过期时间是 500ms），而新来的高优先级任务（100ms），那显然高优先级的任务更小。
- 堆的
bubbleUp机制会自动把高优先级任务“推”到最上面。
于是，React 会立刻停止当前的渲染，转而去执行那个“提交表单”的任务。这就是优先级提升。
这个过程是自动的、实时的。React 就像一个聪明的交警，看到救护车来了（高优先级任务），立马指挥所有车辆让路。
第六部分：过期任务与清理
堆不仅能排序，还能当“保安”。
React Scheduler 还有一个机制叫做过期检查。假设你有一个任务，它的过期时间是 1000ms，也就是 1 秒后必须完成。但是，你的 CPU 很忙，或者用户一直在操作，导致 Scheduler 延迟了 2 秒才开始处理这个任务。
这时候，这个任务已经“过期”了。
在 React 的源码里，当你从堆里 pop 出一个任务时，会检查它的 expirationTime 是否小于当前时间。
function performWorkUntilDeadline() {
while (true) {
// ... 获取任务逻辑 ...
const task = heap.pop();
// 关键代码：过期检查
if (task.expirationTime < now) {
console.warn("任务已过期！虽然很急，但已经来不及了，直接放弃或者降级处理。");
// 在 React 源码中，这里会抛出错误或者执行回退逻辑
continue;
}
// 执行任务...
}
}这种机制保证了 React 不会为了一个已经过期的任务无限期地阻塞主线程。如果任务太慢，或者太慢了，它就会被标记为过期。在 React 中，这通常意味着给用户展示一个“加载中”的骨架屏，而不是让页面彻底卡死。
第七部分：深度剖析——为什么不用 Array.sort()？
你可能会问：“我直接用数组存，每次执行前 array.sort() 一下不就行了？”
来，咱们算笔账。
假设你有 10,000 个任务。
- Array Sort ($O(N log N)$)：每次执行前，你都要把这 10,000 个数字排序一遍。虽然 $N log N$ 不算太慢，但在 React 这种高频调度的场景下，每次排序都是巨大的开销。
- Min Heap ($O(log N)$)：每次插入新任务，只需要调整路径上的几个节点（最多 $log N$ 个）。每次取出任务，也只需要调整路径上的几个节点。
React Scheduler 是一个持续运行的系统，任务会源源不断地进来（比如每个组件渲染都会产生新的任务），也会源源不断地出去。用堆，就像是用一个永远保持有序的队列，而不是每次都要重新排一次队。
第八部分：源码级别的“透视眼”
最后，咱们稍微窥探一下 React 源码中那个著名的 Scheduler 包。
在 React 源码的 packages/scheduler/src/Scheduler.js 里，你会看到 new Task(...) 的调用。那个 Task 对象里，除了 callback 和 expirationTime，还有 sortIndex。
注意那个 sortIndex。在 React 18 之前，sortIndex 只是一个静态的标记。但在 React 18 的并发模式中，sortIndex 是动态变化的。这就是为什么堆里的元素可以随时上下浮动。
另外，你还会看到 requestHostCallback。React 根据环境不同，会使用不同的底层机制：
- setTimeout：最原始，最慢，但兼容性最好。
- MessageChannel：基于 MessageEvent，性能更好，可以更精确地控制时间切片。
- requestAnimationFrame：基于浏览器的重绘周期，如果浏览器正在渲染，React 就不抢占。
React Scheduler 就像一个精明的谈判专家，它根据当前浏览器的状态，选择最合适的“谈判方式”来确保任务能被执行。
结语：调度器的哲学
好了，同学们。
React Scheduler 不仅仅是一堆代码，它是一种设计哲学。它解决了“单线程计算”与“多任务并发”之间的矛盾。它利用最小堆这种高效的数据结构，构建了一个公平而又灵活的调度系统。
在这个系统中，每一个任务都有它的尊严（优先级），每一个时间片都被充分利用，每一个用户操作都能得到及时响应。
当你下次在 React 开发中遇到“闪烁”或者“卡顿”时，不要只怪代码写得太烂。想想那个藏在源码深处的 Scheduler，它可能正拿着最小堆，在幕后默默地为你计算着最优的执行方案。
记住，计算机科学里没有银弹，但最小堆和 React Scheduler 的结合，绝对是一把闪闪发光的银剑。
好了，今天的讲座就到这里。下课！