各位同学，大家下午好！
请把手机调至静音，把电脑屏幕调亮。今天我们要聊的话题，听起来可能有点枯燥，甚至有点吓人——“任务调度”。
但是，别跑！今天我们不聊怎么在钉钉上点“下班”，也不聊怎么在周报里把“摸鱼”美化成“深度思考”。今天，我们要聊聊 React 18 核心库 scheduler 里那个神秘的、像瑞士军刀一样锋利、像黑洞一样深邃的机制——最小堆。
我知道，一听到“堆”和“算法”，你们的大脑皮层已经开始分泌皮质醇了。但请相信我，我会用最通俗的语言、最形象的比喻，甚至是一点点“黑客帝国”式的代码，带你把这东西嚼碎了、咽下去。
准备好了吗？咱们开始吧。
第一章：浏览器是个“懒汉”，而 React 是个“强迫症”
首先，我们得搞清楚一个环境背景。你们平时写 React，觉得浏览器渲染很快对吧？点击一下按钮，界面瞬间就变了。这背后其实是一场猫鼠游戏。
浏览器是单线程的。它的主线程上跑着 JavaScript，同时也负责绘制界面、处理用户输入。这意味着什么？意味着如果 JS 在跑一个死循环，或者算一个超级复杂的数学题，你的整个页面就会“卡死”，连滚动条都动不了。这就是所谓的“阻塞式渲染”。
在 React 18 之前，React 就像个不懂得“见好就收”的强迫症。你把任务交给它，它就闷头干到底。不管这个任务是“计算一下当前时间”这种高优先级任务，还是“渲染一万个列表项”这种低优先级任务，它都一视同仁，一股脑儿全干完。这就是为什么 React 18 之前，如果网络慢，输入框都打不出字。
于是，React 团队引入了 Scheduler。Scheduler 的核心任务只有一个：决定什么时候干活，以及什么时候把控制权交还给浏览器。
这就好比一个厨房的指挥官。厨房里有厨师（渲染任务）、有服务员（用户输入）、有洗碗工（后台任务）。以前指挥官大喊一声“全上！”，结果服务员在等菜，厨师在洗碗，乱成一锅粥。
现在，Scheduler 上线了。它手里拿着一个 “最小堆”（Min-Heap）。
第二章：为什么非得用“最小堆”？难道数组不行？
你可能会问：“老哥，咱们平时存数据用数组（Array）不香吗？push 进去，shift 取出来，简单粗暴。干嘛非得整一个树形结构？”
好问题！这触及到了算法设计的灵魂——效率。
假设我们现在有 100 个任务，优先级各不相同。我们需要一个数据结构，能够：
- 随时插入新任务。
- 随时取出优先级最高的那个任务。
如果我们用数组：
- 插入：
push，平均是 O(1)。这还行。 - 取出：我们要找那个优先级最高的（也就是
sortIndex最小的），怎么找？Array.sort()一次，或者遍历一遍。这可是 O(n)。如果有 1000 个任务，每次取任务都要遍历 1000 个，这太慢了！CPU 都要被你累死。
如果我们用最小堆：
- 插入：把新任务扔到数组末尾，然后“上浮”调整。这个过程最多需要 O(log n) 步。如果堆里有 1000 个节点，log(1000) 也就 10 步。这很高效！
- 取出：直接把堆顶（数组第一个元素）拿出来。然后把堆底的那个“倒霉蛋”搬到堆顶，然后“下沉”调整。这个过程也是 O(log n)。
结论： 在 React 这种高频调度的场景下，数组简直就是“拖拉机”，而最小堆就是“法拉利”。
第三章：手把手教你写一个 React Scheduler 的堆
别怕，我们不看 React 源码里那些被压缩过的、让人头秃的代码，我们从头造一个轮子。这个轮子就是 Scheduler 的核心。
3.1 定义任务
首先，我们要给每个任务定个性。在 React 里，每个任务都有一个 sortIndex（排序索引）。这个数字越小，优先级越高。时间越早，sortIndex 越小。
// 这是一个任务对象，它是堆的基本单元
const task = {
id: 1,
callback: () => console.log('干活了！'),
sortIndex: 10, // 数字越小，越急
// ... 更多属性
};3.2 堆的核心数据结构
最小堆本质上是一个完全二叉树，存储在数组里。对于数组中的任意索引 i：
- 它的左孩子索引是
2 * i + 1 - 它的右孩子索引是
2 * i + 2 - 它的父节点索引是
Math.floor((i - 1) / 2)
关键规则： 父节点的值必须小于等于子节点的值。这样，数组第一个元素永远是最小的。
3.3 插入操作
假设我们现在有一个空堆，我们要插入一个 sortIndex 为 5 的任务。
class Heap {
constructor() {
this.items = []; // 存任务的数组
}
// 插入任务
push(task) {
// 1. 把任务加到数组最后
this.items.push(task);
// 2. 开始“上浮”操作
let index = this.items.length - 1;
// 只要这个任务比它的爸爸大，就交换位置
// 注意：这里我们比较的是 sortIndex
while (index > 0) {
let parentIndex = Math.floor((index - 1) / 2);
let parent = this.items[parentIndex];
// 如果新任务的优先级（sortIndex）比爸爸小，说明爸爸该让位了
if (task.sortIndex < parent.sortIndex) {
// 交换
this.items[parentIndex] = task;
this.items[index] = parent;
// 爸爸现在的索引变成了 index，继续往上找爷爷
index = parentIndex;
} else {
// 如果比爸爸大，说明位置对了，不用动了
break;
}
}
}
}想象一下，新任务就像一个调皮的小孩被扔到了队伍末尾。调度员（Heap）会检查他是不是比他前面的人（父节点）更优秀。如果更优秀，就踢他到前面去。这个过程会一直重复，直到他排好队，或者他发现自己其实没那么强。
3.4 取出操作
现在，我们要取出优先级最高的任务。堆顶就是最优秀的那个。
// 取出最高优先级任务
pop() {
const firstItem = this.items[0];
const lastItem = this.items.pop(); // 把最后一个元素拿出来
// 如果堆不是空的，把最后一个元素放到堆顶，开始“下沉”
if (this.items.length > 0) {
this.items[0] = lastItem;
this.sinkDown(0); // 从根节点开始下沉
}
return firstItem;
}
// 下沉操作：把小的往上顶，大的往下沉
sinkDown(index) {
const length = this.items.length;
const element = this.items[index];
while (true) {
let child2Index = (index + 1) * 2;
let child1Index = child2Index - 1;
let swap = null;
// 检查左孩子是否存在，并且左孩子的优先级是否比当前节点高
if (child1Index < length) {
const child1 = this.items[child1Index];
if (child1.sortIndex < element.sortIndex) {
swap = child1Index;
}
}
// 检查右孩子是否存在，并且右孩子的优先级是否比当前节点高（且比左孩子还高）
if (child2Index < length) {
const child2 = this.items[child2Index];
if (
(swap === null && child2.sortIndex < element.sortIndex) || // 左孩子没交换，但右孩子比当前高
(swap !== null && child2.sortIndex < child1.sortIndex) // 左孩子交换了，但右孩子比左孩子还高
) {
swap = child2Index;
}
}
if (swap === null) {
// 没有孩子比他高了，位置稳了
break;
}
// 交换
this.items[index] = this.items[swap];
this.items[swap] = element;
// 继续检查被交换下去的孩子
index = swap;
}
}
}这个过程就像是一场激烈的“宫斗大戏”。堆顶的那个大佬被挤下去了，他得去寻找自己的归宿。如果他有两个更优秀的儿子，他就得去给儿子打工；如果儿子不如他，他就稳坐江山。
第四章：Scheduler 的“时间切片”魔法
有了堆，我们有了存放任务的地方。但是，怎么让任务一个个执行呢？这就涉及到 React Scheduler 的另一个核心——时间切片。
React 不想一次性把所有任务干完，那样会卡死浏览器。它想的是：“我干 5 毫秒，然后歇口气，看看浏览器累不累，或者有没有更急的事插队。”
4.1 事件循环的介入
在浏览器中，requestIdleCallback 是一个神奇的东西。它告诉浏览器：“嘿，当主线程空闲的时候，也就是你在渲染下一帧、处理用户输入的空档期，你可以调用我给的函数。”
React Scheduler 的循环大概长这样：
function workLoop() {
// 1. 从堆里取出下一个最高优先级的任务
const task = heap.pop();
if (task !== null) {
// 2. 执行任务（执行 callback）
task.callback();
// 3. 检查时间！
// 如果当前时间减去开始时间，超过了 5 毫秒，那就停下来
if (shouldYield(now)) {
// 4. 把这个任务重新放回堆里（或者放回队列）
// React 这里逻辑更复杂，涉及到延迟执行，这里简化理解
heap.push(task);
return; // 退出循环，把控制权还给浏览器
}
// 如果没超时，继续下一轮
workLoop();
}
}
// 这是一个判断是否该让步的函数
function shouldYield(now) {
// 如果浏览器有空闲时间，或者时间到了，就返回 true
return now - startTime > 5; // 假设每次切片 5ms
}注意看这里的逻辑： 当我们执行完一个任务，并没有直接退出，而是继续调用 workLoop()。如果时间到了，我们就 return。下一次浏览器空闲时，requestIdleCallback 会再次把我们唤醒，我们继续从堆里取任务。
这就实现了可中断的渲染。
4.2 优先级的动态调整
React Scheduler 的厉害之处还在于，它不仅能调度任务，还能抢占任务。
假设你现在正在渲染一个低优先级的列表（比如背景更新），突然用户点击了一个“提交”按钮（高优先级）。React Scheduler 会立即把那个“提交”任务插入到堆的顶部。
下一次循环开始，heap.pop() 取出来的就是“提交”任务。它会立即执行，打断之前的低优先级渲染。
这就像你在做饭（渲染列表），突然电话响了（用户点击）。你把锅盖一盖（中断渲染），去接电话（执行高优先级任务）。接完电话，你回来继续做饭。
第五章：深入 React 的优先级体系
React 18 引入了很多新的优先级常量。如果你去看源码，你会看到一长串像这样的变量：
const ImmediatePriority = 1;
const UserBlockingPriority = 2;
const NormalPriority = 3;
const LowPriority = 4;
const IdlePriority = 5;这其实就是 sortIndex 的值。
- ImmediatePriority (1)：最高级。比如
setState触发的同步更新。 - UserBlockingPriority (2)：用户阻塞级。比如用户正在输入，我们需要立即响应。
- NormalPriority (3)：普通级。比如
useEffect的清理函数。 - LowPriority (4)：低级。比如
useTransition里的过渡状态更新。 - IdlePriority (5)：空闲级。比如完全不需要马上看的东西。
React 内部有一个函数 runWithPriority，它会根据你传入的优先级，动态调整 sortIndex，然后把这个任务扔进堆里。
function runWithPriority(priorityLevel, eventHandler) {
// 1. 记录当前的优先级
const previousPriority = currentPriorityLevel;
// 2. 设置新的优先级
currentPriorityLevel = priorityLevel;
// 3. 执行回调
try {
return eventHandler();
} finally {
// 4. 恢复之前的优先级（非常重要！防止低优先级任务覆盖高优先级）
currentPriorityLevel = previousPriority;
}
}这里有个非常经典的面试题陷阱：为什么要在执行完回调后恢复优先级？
因为如果你在执行回调的过程中，回调函数里又调用了 setState，如果不恢复优先级，你刚刚设置的“高优先级”就会失效，被当前的“低优先级”给覆盖掉。这会导致界面卡顿，用户体验极差。所以，恢复优先级是防止“优先级倒灌”的关键。
第六章：useTransition —— React 给你的“暂停键”
React 18 新增的 useTransition Hook，就是基于 Scheduler 做的糖衣炮弹。
以前，你写 setState 更新列表，如果列表很长，页面会卡顿。现在，你可以用 startTransition 把它包起来。
import { startTransition, useState } from 'react';
export default function App() {
const [input, setInput] = useState('');
const [list, setList] = useState([]);
// 这个输入框是高优先级
const handleChange = (e) => {
setInput(e.target.value);
// 这个列表更新是低优先级（过渡状态）
startTransition(() => {
// 计算列表很耗时，但不会阻塞输入框
const filtered = data.filter(item => item.includes(input));
setList(filtered);
});
};
return (
<div>
<input onChange={handleChange} value={input} />
{list.map(item => <div key={item}>{item}</div>)}
</div>
);
}在底层，startTransition 其实就是调用了一个 Scheduler 的低优先级 API。
// 底层伪代码
function startTransition(update) {
// 1. 告诉 Scheduler，接下来我要干的事是 LowPriority
// 2. 执行 update
// 3. 如果用户还在输入，Scheduler 会不断取消之前的 LowPriority 任务
// 直到用户停下，才执行一次完整的更新
unstable_runWithPriority(LowPriority, update);
}这就像你给 Scheduler 发了一个信号：“大哥，后面那个列表更新我不急，等会儿再弄。但是这个输入框，必须实时响应！”
第七章：取消任务与并发调试
React 18 还提供了一个调试工具 useSyncExternalStore 和 useDeferredValue，这些都依赖于 Scheduler 的能力。
但最酷的功能之一是任务取消。
有时候，我们发起了网络请求，但用户跳转了页面。此时，这个请求对应的更新任务应该被取消，否则用户回到页面时，会看到旧的数据覆盖新页面。
在 Scheduler 的实现中，每个任务都有一个 node。我们可以通过 cancelCallback 来移除这个节点。
function cancelScheduledCallback(node) {
// 1. 找到这个节点在堆里的位置
const index = heap.indexOf(node);
// 2. 如果找到了，把它从堆里删掉
if (index !== -1) {
heap.splice(index, 1);
}
// 3. 断开引用，防止内存泄漏
node.callbackNode = null;
}这就像你雇了一个临时工（任务），他正在搬砖（执行）。结果你发现工头（React）已经换新工作了。于是你立刻把临时工叫停，告诉他不用来了。
第八章：那些年我们踩过的坑
虽然 Scheduler 很强大，但实现它并不容易。这里有几个 React 团队可能遇到过的“坑”。
8.1 堆的稳定性
堆虽然快，但是它的操作会改变数组顺序。如果我们在遍历堆的时候，突然插入了新元素，可能会导致死循环或者索引错误。所以，Scheduler 在处理并发任务时，对堆的操作非常谨慎，通常会采用“双缓冲”或者“标记删除”的策略，而不是直接修改正在遍历的堆。
8.2 时间估算的误差
requestIdleCallback 的 deadline 是一个估计值。浏览器说“你有 50ms 的时间”，但实际可能只有 30ms，因为浏览器还要处理其他事件。如果 React 没有及时检测到超时，就会导致页面闪烁。所以，shouldYield 函数必须精确地检测 now - startTime。
8.3 边界情况：任务过期
如果一个高优先级任务在堆里等了太久（比如超过了 expirationTime），它就过期了。React 必须强制执行这个过期任务，即使它会阻塞浏览器一小会儿。这保证了系统的最终一致性。
第九章：实战演练 —— 手写一个简易版 Scheduler
好了，理论讲得够多了，我们来写一个能跑的 Demo。这不是 React，但它是 React Scheduler 的灵魂。
这个 Demo 包含：
- 一个任务队列（数组）。
- 一个执行器。
- 一个优先级调度器。
// 1. 定义任务
class Task {
constructor(id, priority, callback) {
this.id = id;
this.priority = priority; // 越小越优先
this.callback = callback;
this.deadline = null;
}
}
// 2. 简单的调度器
class SimpleScheduler {
constructor() {
this.queue = []; // 模拟堆，实际应用中请用 Heap
this.isRunning = false;
}
// 添加任务
schedule(task) {
this.queue.push(task);
// 简单排序：每次插入后都排序一下（实际生产环境太慢，要用堆）
// 为了演示方便，这里用 sort，实际 React 用的是 O(log n) 的堆
this.queue.sort((a, b) => a.priority - b.priority);
if (!this.isRunning) {
this.isRunning = true;
this.loop();
}
}
// 执行循环
loop() {
if (this.queue.length === 0) {
this.isRunning = false;
return;
}
// 取出最高优先级
const task = this.queue.shift();
console.log(`执行任务 ${task.id}, 优先级: ${task.priority}`);
// 执行回调
const startTime = performance.now();
task.callback();
const endTime = performance.now();
// 模拟时间切片：如果执行时间超过 5ms，就暂停，让出控制权
if (endTime - startTime > 5) {
console.log(`任务 ${task.id} 耗时过长，休息一下...`);
// 重新放入队列末尾（或者放入一个延迟队列）
// 这里为了演示，我们重新放回队列末尾，稍微降低一点优先级
task.priority += 10;
this.queue.push(task);
// 稍微 setTimeout 一下，让出主线程
setTimeout(() => {
this.loop();
}, 0);
return;
}
// 继续下一个
this.loop();
}
}
// --- 测试一下 ---
const scheduler = new SimpleScheduler();
// 模拟几个任务
// 1. 高优先级：处理用户点击
scheduler.schedule(new Task(1, 1, () => {
console.log('>> 处理用户点击事件');
}));
// 2. 中优先级：计算数据
scheduler.schedule(new Task(2, 5, () => {
console.log('>> 计算数据中...');
// 模拟耗时操作
const start = Date.now();
while(Date.now() - start < 100) {}
console.log('>> 数据计算完成');
}));
// 3. 低优先级：更新 UI
scheduler.schedule(new Task(3, 10, () => {
console.log('>> 更新 UI');
}));运行这段代码，你会发现，虽然任务 2（计算数据）很耗时，但它没有把任务 1（处理点击）给卡死。任务 2 被迫中断，稍后继续。这就是 React Scheduler 的魔力。
第十章：未来展望 —— 更好的调度
React 团队并没有止步于此。随着浏览器 API 的发展，scheduler 也在进化。
比如，针对移动端或者性能较差的设备，React 会自动降低时间切片的长度，或者减少并发渲染的深度，以保证页面不卡顿。这就是所谓的“自适应调度”。
另外，React 正在探索更细粒度的调度，不仅仅是任务级别的调度，还有帧级别的调度。这意味着，我们可以在每一帧的 16ms 限制内，更精细地安排渲染任务。
结语：算法之美
讲了这么多，React Scheduler 最小堆的本质是什么？
它不是魔法，它是秩序。
在一个混乱的、多任务并发的浏览器环境中，React 通过最小堆这个数据结构，建立了一套严格的秩序。它让急事先办，让慢事后办，让重要的事不被琐碎的事淹没。
当你下次在 React 18 的应用中，点击按钮依然流畅如丝，列表滚动依然丝般顺滑时，请记得，在屏幕的背后，有一个看不见的调度员，正拿着一个最小堆，精打细算地分配着每一毫秒。
这就是代码的艺术，这就是工程的力量。
好了，今天的讲座就到这里。下课！
（如果你觉得这节课有用，记得给 React 团队点个赞，顺便给写这篇文章的我点个赞。下次课，我们聊聊 React Fiber 那个让人抓狂的树结构。再见！）