各位同学，大家好！
今天我们不讲组件，不讲 Hooks，也不讲那些花里胡哨的 JSX 语法糖。今天，我们要钻进 React 的核心深处，去看看它的“大脑皮层”——也就是那个神秘莫测的 调度器。
想象一下，你是一家米其林星级大厨。你的厨房里有一排排锅（这就是我们的 React 组件树），你需要根据客人的订单（用户的操作）来决定先炒哪道菜。有些客人点了“红烧肉”（高优先级，比如你正在输入框里打字），有些客人点了“凉菜”（低优先级，比如后台的数据同步）。
这时候，问题来了：如果红烧肉这道菜特别难做，耗时极长，你把厨师长（主线程）都拖住了，那凉菜是不是就彻底凉了？甚至，凉菜永远凉了，因为厨师长永远在红烧肉那儿死磕，根本没空看一眼凉菜。
在计算机科学里，这叫 任务饥饿。而在 React 的世界里，我们怎么防止这种情况发生？怎么确保那个后台的凉菜最终还是被吃掉了？靠的不是魔法，靠的是一个非常精妙的数学模型——ExpirationTime（过期时间）模型。
来，搬好小板凳，我们开始这场关于“时间与截止日期”的深度解剖。
一、 什么是任务饥饿？一场厨房里的“冷宫”悲剧
在讲代码之前，我们先把这个概念具象化。
假设我们有一个 React 应用。用户在页面上疯狂输入文字（这通常是个高优先级任务，我们要保证输入的延迟极低，几乎不能有卡顿）。同时，应用里还有一个后台任务，比如从服务器拉取几百条用户评论，并在页面上渲染列表。
正常情况下，用户输入的时候，输入事件触发，React 决定：“好，我先暂停后台拉评论，先处理这个输入！”这是合理的。但是，如果用户突然不输入了，或者说，用户的网络特别慢，那后台拉评论的任务该怎么办？
如果你是那种“傻傻的”调度器，你可能会说：“好的，用户不输入了，那我把后台任务拿上来做吧。” 恭喜你，你复活了后台任务。
但现实是残酷的。浏览器的主线程只有一颗脑袋。如果这个后台任务特别重，耗时 500 毫秒。就在这 500 毫秒里，用户可能打了两行字，或者点击了一个按钮。调度器一看：“哎呀，新任务来了，这是个 VIP！” 于是，调度器说：“抱歉，评论列表你先等等，用户的新点击更重要。”
于是，评论列表的任务被挂起。等这个 500 毫秒的高优先级任务处理完，调度器再次检查队列，发现评论列表还在那儿。它可能会想：“哎，还没做完吗？那再等等吧。” 结果，用户又打了几行字。
就这样，评论列表的任务就像是被流放的妃子，在冷宫里瑟瑟发抖，永远没有执行的一天。这就是任务饥饿。页面主线程被高优先级任务填满，低优先级任务（虽然叫低优先级，但用户还是想看！）实际上死掉了。
二、 解决方案：ExpirationTime 模型
React 不想当那种流放妃子的暴君。它发明了一个机制，给每一个任务都贴了一张“生死符”。这张符上写着一个时间点，叫做 ExpirationTime。
你可以把 ExpirationTime 想象成一个倒计时的炸弹，或者是给厨师长下的最后通牒。
- ExpirationTime 的含义：这是任务必须完成的最晚时间点。
- 为什么需要它：如果超过了这个时间还没做完，React 就会认为这个任务“过期”了。一旦过期，这个任务就会像疯狗一样“强制提升”优先级，或者被重新插队到队列的最前面，必须马上执行。
这个模型的核心理念是：我们不承诺任务一定能完成，但我们承诺，只要你活着（没过期），你就必须被喂饱。
三、 代码示例：一个简单的饥饿模拟器
为了让你们直观地理解，我先写一段伪代码，模拟一个没有 ExpirationTime 模型的调度器，展示一下它是如何饿死任务的。
// 一个简单的任务队列
const taskQueue = [];
// 添加任务
function scheduleTask(task) {
taskQueue.push(task);
// 没有优先级排序，也没有过期检查，直接扔进去
// 执行逻辑
processQueue();
}
function processQueue() {
while (taskQueue.length > 0) {
const task = taskQueue.shift(); // 取出第一个任务
console.log(`正在执行: ${task.name}`);
// 模拟耗时操作
task.run();
// 假设这里每执行 50ms 就会有一个高优先级任务插入
if (Math.random() > 0.5) {
const highPriorityTask = {
name: '用户点击事件',
run: () => console.log('!!! 抢占优先级：处理用户点击 !!!')
};
taskQueue.unshift(highPriorityTask); // 插队到队头
}
}
}
// 场景演示
scheduleTask({ name: '渲染列表', run: () => {
// 假设这个渲染需要 200ms
console.log("开始渲染列表 (耗时较长)...");
setTimeout(() => console.log("渲染列表完成"), 200);
}});在这个糟糕的调度器里，渲染列表 这个任务一旦开始执行，它就会一直跑到完。因为它是第一个被取出的。如果中间插队了用户点击事件，它会被重新放到队头，导致 渲染列表 被彻底挤到队列末尾，甚至永远执行不到。
四、 加入ExpirationTime：时间的魔法
现在，让我们给这个调度器加点料。我们要引入 expirationTime。每个任务创建时，都会根据它的优先级被分配一个 expirationTime。
class Task {
constructor(name, priority) {
this.name = name;
this.priority = priority; // 1: 低, 2: 中, 3: 高
// 核心机制：根据优先级计算过期时间
// 假设：高优先级 5ms，中优先级 50ms，低优先级 100ms
if (priority === 3) this.expirationTime = Date.now() + 5;
else if (priority === 2) this.expirationTime = Date.now() + 50;
else this.expirationTime = Date.now() + 100;
}
}
// 改进后的调度器
const taskQueue = [];
function scheduleTask(task) {
taskQueue.push(task);
// 排序：谁离过期时间近，谁先跑
taskQueue.sort((a, b) => a.expirationTime - b.expirationTime);
processQueue();
}
function processQueue() {
const now = Date.now();
while (taskQueue.length > 0) {
const task = taskQueue[0]; // 查看队首（即将要执行的）
// 关键检查：如果当前时间已经超过了任务的过期时间
if (now >= task.expirationTime) {
console.log(`⚠️ 警告：任务 [${task.name}] 已过期！强制提升优先级！`);
// 策略 A：重置过期时间，让它变得极其紧迫
task.expirationTime = now + 10;
// 策略 B：或者直接让它插队，优先级变高
taskQueue.shift();
taskQueue.push(task);
continue;
}
// 正常执行
console.log(`执行: ${task.name} (截止时间: ${task.expirationTime})`);
task.run();
taskQueue.shift();
// 模拟外部干扰
if (Math.random() > 0.5) {
const highPriorityTask = new Task('用户点击', 3);
scheduleTask(highPriorityTask);
}
}
}
// 开始测试
console.log("=== 场景：后台渲染任务开始，随后用户点击 ===");
const longTask = new Task('渲染列表', 1); // 低优先级，截止时间晚
scheduleTask(longTask);看懂了吗？就是这个逻辑在起作用。
- 初始状态：
渲染列表被加入队列。它的expirationTime是现在 + 100ms。它排在最后面。 - 执行中：调度器开始运行。
渲染列表启动了。 - 外部冲击：
用户点击进来了。这是个高优先级任务，截止时间是现在 + 5ms。它被插入队列。 - 插入排序：因为
用户点击的expirationTime（现在+5ms）比渲染列表（现在+100ms）早，所以用户点击排到了队头。 - 执行：
用户点击被执行。 - 再次检查：
渲染列表还是排在后面。假设用户点击执行了 10ms，时间到了。 - ExpirationTime 介入：此时，
渲染列表可能已经挂起（或者因为某些原因被阻塞）了超过 100ms。此时now >= task.expirationTime。 - 强制提升：代码里的
if (now >= task.expirationTime)触发了。调度器大喊一声：“嘿！那个渲染列表，你超时了！你现在立刻插队！” - 结果：
渲染列表被移到队尾（或者队头，取决于具体实现），它的expirationTime被重置为一个极短的时间（比如 5ms）。这意味着，只要主线程一有空，它就必须马上被处理。
这就是 React 调度器防御饥饿的核心逻辑：用时间换取公平。
五、 React 源码深究：那一串令人头秃的数字
光看伪代码还不够劲，我们得看看 React 真正干了什么。React 的源码（特别是 Scheduler 模块）非常硬核，充满了数学公式和极限情况的处理。
在 React 中，并没有简单的 if (time > expiration) 这样一句话。它用的是 startTime（任务开始时间）和 currentTime（当前时间）。
1. timeout 的计算
当 React 创建一个任务时，它会根据优先级决定这个任务的最大允许耗时。
React 的优先级是从 0 到 99 的数值。数值越大，优先级越高。
timeout = currentTime + priorityLevel * 1000（这只是个简化的公式，实际逻辑更复杂，涉及不同的层级：Sync, Action, Continuous, UI, Idle）。
2. resetExpirationTime：时间的重置
这是最关键的部分。在 React 的调度循环中，有一个 shouldYield 的概念。
// 这是一个极度简化版的 React 调度器逻辑
function workLoop() {
while (nextUnitOfWork !== null) {
// 1. 执行当前任务
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
// 2. 检查是否需要让出主线程（给浏览器渲染机会）
if (shouldYieldToHost()) {
return; // 停下来，让浏览器刷新
}
// 3. 核心逻辑：检查是否过期
// 如果当前时间 >= nextUnitOfWork 的 expirationTime
if (now() >= nextUnitOfWork.expirationTime) {
// 任务过期了！
// 我们需要强制完成它，或者降低优先级
// 在 React 中，这通常通过重置 expirationTime 并重新调度来实现
nextUnitOfWork = resetExpirationTime(nextUnitOfWork);
}
}
}resetExpirationTime 函数在 React 源码里是这样的逻辑：
function resetExpirationTime(currentTime) {
// 如果任务已经完成了，那就别管了
if (isFinished(workInProgress)) {
return null;
}
// 获取任务的优先级
const priorityLevel = getCurrentPriorityLevel();
// 关键点：如果任务已经过期，React 会给它一个新的、更紧迫的截止时间
// 这就像是在说：“你迟到了！现在必须马上完成！”
const newExpirationTime = currentTime + priorityLevel * 1000;
// 更新任务的过期时间
currentWorkInProgress.expirationTime = newExpirationTime;
// 返回任务，让调度器下次循环优先执行它
return currentWorkInProgress;
}六、 为什么这样设计能防止饥饿？
你可能会问：“这就给它加个时间限制，它执行不完怎么办？”
好问题。React 不指望它一次性执行完（那是那台吃CPU的怪兽——ReactDOM.render 的问题）。React 依赖的是协作式多任务处理。
- 时间切片：React 把一个大任务切成了无数个小片。
- ExpirationTime：每一片都有一个截止时间。
想象一下，你有一堆作业要写。每写 5 分钟，老师就进来查一下。如果你前 10 分钟都在打游戏，老师进来了，一看你还没动笔，而且截止时间（ExpirationTime）快到了。老师就会说：“停下游戏！立刻写作业！”
这就是 expirationTime 的作用。它迫使命令行环境（JavaScript 单线程）不断地停下来，检查这个“截止时间”。如果任务没完成，它就会被强制安排到下一次循环的优先级顶端。
场景还原：高优先级任务封锁低优先级任务
让我们把这个场景写得更具体一点，模拟一个真实的 React 渲染循环。
时刻 0ms：用户点击了按钮。
时刻 0ms – 5ms：React 调度器收到点击事件。这是一个高优先级任务（priority = 99）。
时刻 5ms：调度器设置这个任务的 expirationTime = now + 100ms（给它 100ms 的缓冲时间）。
时刻 5ms – 105ms：调度器开始执行这个高优先级任务。这期间，可能有 50ms 的时间过去了。
时刻 55ms：用户开始拖动滚动条。这是一个中等优先级任务（priority = 25）。
时刻 55ms：调度器将滚动任务插入队列。
时刻 55ms – 60ms：高优先级任务还在跑。
时刻 60ms：调度器再次循环。它检查队列。
- 滚动任务：
expirationTime = now + 50ms(假设中等优先级是 50ms)。 - 高优先级任务：
expirationTime = 5ms + 100ms = 105ms。 - 对比：
55 + 50 = 105。滚动任务的截止时间是 105ms，高优先级是 105ms。平局？通常滚动任务会被优先执行，因为它更实时。 - 结果：高优先级任务被挂起，滚动任务开始执行。
时刻 60ms – 110ms：滚动任务执行。这期间，高优先级任务一直被挂起。
时刻 110ms：高优先级任务开始执行。但是，计算一下它的expirationTime。5ms + 100ms = 105ms。现在是 110ms。
时刻 110ms：110ms >= 105ms。判定：高优先级任务过期了！
时刻 110ms：React 调度器大喊：“停！高优先级任务超时了！它被饿死了！现在把它插队到最前面！强制执行！”
这一瞬间，滚动任务（即使是用户正在进行的操作）会被挂起，以让那个被饿死的高优先级任务执行。这就是 ExpirationTime 强制提升 的威力。
七、 代码示例：实战 React 调度器的行为
为了让大家更有感觉，我们不用 React 库本身，而是手写一个极简版的 Scheduler，模拟 React 的行为。
// 模拟浏览器环境
let now = () => Date.now();
class SimpleScheduler {
constructor() {
this.currentTask = null;
this.tasks = [];
this.isRunning = false;
}
// 计算过期时间：当前时间 + 优先级系数
// 优先级越高，系数越小（越快过期），但这里为了演示，我们假设优先级数字越大越重要
// 在 React 里，数值越大越重要。我们设定：priority 99 -> 1ms, priority 25 -> 100ms
calculateExpirationTime(priority) {
const priorityFactor = Math.max(1, 1000 / (priority + 1)); // 简单的反比关系
return now() + priorityFactor;
}
schedule(priority, taskName, callback) {
const expirationTime = this.calculateExpirationTime(priority);
const task = {
id: Math.random().toString(36).substr(2, 9),
priority,
expirationTime,
name: taskName,
callback
};
this.tasks.push(task);
// 简单的排序：谁快过期谁先排
this.tasks.sort((a, b) => a.expirationTime - b.expirationTime);
if (!this.isRunning) {
this.run();
}
}
async run() {
this.isRunning = true;
while (this.tasks.length > 0) {
const currentTime = now();
// 取出队首任务
const task = this.tasks[0];
// 检查任务是否过期
// 核心防御逻辑：如果当前时间超过了任务的截止时间，说明它被饿太久了
if (currentTime >= task.expirationTime) {
console.log(`🔴 [饥饿检测] 任务 ${task.name} 过期了！被强制插队！`);
// 1. 重新计算过期时间（强制提升）
// React 策略：给它一个新的、非常紧迫的截止时间，确保下次循环能拿到
task.expirationTime = currentTime + 5;
// 2. 移到队尾（或者队头，取决于具体优先级比较策略）
// 这里我们模拟 React 的行为：过期任务通常会立刻尝试执行
this.tasks.shift();
this.tasks.push(task);
// 3. 跳过本次循环的排位检查，直接执行这个“过期的”
// 模拟执行
await this.executeTask(task);
continue;
}
// 正常执行队首任务
console.log(`🟢 执行任务: ${task.name} (剩余时间: ${Math.floor(task.expirationTime - currentTime)}ms)`);
await this.executeTask(task);
// 移除已执行任务
this.tasks.shift();
// 模拟让出主线程（给浏览器渲染机会）
await new Promise(resolve => setTimeout(resolve, 10));
}
this.isRunning = false;
console.log("所有任务执行完毕");
}
executeTask(task) {
return new Promise(resolve => {
setTimeout(() => {
console(` -> ${task.name} 完成`);
resolve();
}, Math.random() * 50); // 随机耗时
});
}
}
// 启动调度器
const scheduler = new SimpleScheduler();
console.log("=== 模拟场景：高优先级任务阻塞低优先级任务 ===n");
// 1. 启动一个低优先级任务（比如拉取评论）
// 优先级 25，假设耗时 100ms，那 expirationTime 就是 now + 100ms
scheduler.schedule(25, '后台加载评论', () => {
console.log(" -> 加载评论数据...");
});
// 2. 50ms 后，用户点击了一个按钮（高优先级）
// 优先级 99，假设耗时 50ms，那 expirationTime 就是 now + 1ms (极短)
setTimeout(() => {
console.log("n--- 用户点击了按钮 (高优先级) ---");
scheduler.schedule(99, '处理按钮点击', () => {
console.log(" -> 处理按钮点击逻辑...");
});
}, 50);
// 3. 120ms 后，用户拖动了滑块（中等优先级）
setTimeout(() => {
console.log("n--- 用户拖动了滑块 (中等优先级) ---");
scheduler.schedule(50, '更新滑块位置', () => {
console.log(" -> 更新滑块位置...");
});
}, 120);运行这段代码，你会看到什么？
后台加载评论启动。它的截止时间是现在+100ms。- 50ms 时，
处理按钮点击启动。它的截止时间是现在+1ms（极短）。它插队，开始执行。 - 100ms 时，
处理按钮点击还在跑。此时后台加载评论的截止时间到了（now >= expirationTime）。 - 关键点来了：调度器检测到过期，它不会乖乖排队。它会把这个任务拿出来，重新计算截止时间为
now+5ms，然后再次执行。 - 因为
处理按钮点击还没完，后台加载评论被再次插队。它可能要等待好几次处理按钮点击的间隙才能执行。 - 最终，
后台加载评论会完成，因为它被强制“唤醒”了很多次。
这就是 expirationTime 如何通过周期性的重置和重新调度，打破了高优先级任务的垄断，防止了低优先级任务的饥饿。
八、 细节狂魔：ExpirationTime 的策略
在 React 的源码中，ExpirationTime 不仅仅是防止饥饿的工具，它还是决定渲染策略的指挥棒。
1. Sync, Action, Continuous, UI, Idle
React 对任务进行了分级，每一级都有一个对应的 timeout 值。
- Sync (同步任务)：比如
ReactDOM.render的入口。它的expirationTime是MAX_EXPIRATION_TIME（一个极大的数字）。这意味着它不会被时间强制打断，它必须阻塞直到完成。这确保了初始化是稳定的。 - Action (用户操作)：比如
onClick。它的 timeout 很短，确保输入响应迅速。 - Idle (空闲任务)：比如
requestIdleCallback。它的 timeout 很长，甚至可能永远不会过期。这意味着它容忍饥饿。
2. 过期任务的后果
当一个任务过期时，React 会做什么？
如果任务过期了，React 会认为用户界面已经卡顿了。这时候，React 有两个选择：
- 降低优先级并继续：如果这个任务已经执行了一部分，React 可能会把它降级为 Idle，不再阻塞 UI 线程，而是放到后台慢慢跑。这避免了页面彻底假死。
- 重置并抢占：这就是上面讲的。强制它完成，或者至少让它变得紧迫。
在 React 的 Fiber 架构中，这通常表现为 resetExpirationTime。如果工作正在 workInProgress 树上进行，并且时间到了，React 会检查当前任务的 expirationTime。如果它过期了，React 会重新调度任务。
九、 总结：ExpirationTime 是一种“时间贿赂”
我们来总结一下。React 调度器中的 expirationTime 模型，本质上是一种基于截止时间的激励系统。
它告诉调度器：“嘿，别只看任务有多急（Priority），还要看它是不是已经老糊涂了（Starvation）。如果一个任务在这个时间点之前没做完，它就得立刻变成最急的任务！”
给开发者的启示：
理解这个模型，对写高性能 React 代码至关重要。
- 不要过度使用高优先级：不要随便在组件里用
setTimeout来强行提升任务优先级（除非你用了scheduler.postTask或scheduler.runWithPriority）。因为如果你给了任务过短的expirationTime，它会被反复抢占，导致其他任务饥饿。 - 善用
useTransition：React 提供了startTransition，这本质上就是告诉调度器：“嘿，这个任务虽然重要，但不需要阻塞整个渲染。给我分配一个较长的expirationTime。” 这样它就不会因为被高优先级任务打断而频繁过期重排，从而保证了页面的流畅性。 - 理解 Deadline：在
scheduler包中，你经常会看到deadline对象。这个对象包含了didTimeout属性。如果你自己在写调度器或者使用schedulerAPI，一定要检查didTimeout。如果为true，说明你的任务过期了，必须立即处理！
十、 一个更复杂的代码示例：模拟 React 的 requestPaint
React 还有一个机制叫 requestPaint。它是用来在时间切片中强制浏览器立即绘制一帧的。
结合 expirationTime 和 requestPaint，逻辑是这样的：
function workLoopScheduler() {
// 记录开始时间
const startTime = now();
while (nextUnitOfWork) {
// 1. 执行工作
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
// 2. 检查是否过期
const currentTime = now();
if (currentTime - startTime > task.expirationTime) {
// 任务已过期！强制渲染
requestPaint(); // 告诉浏览器：“别偷懒，赶紧把这帧画出来！”
return;
}
}
}这里，requestPaint 是一种暴力手段。即使时间还没到，为了防止低优先级任务被饿死，React 也会逼迫浏览器渲染一帧。这也就是为什么 React 的动画有时候会感觉有点“抖动”或者偶尔闪烁——因为它在为了公平性，强制牺牲了帧率的一致性，去抢救那些被遗忘的任务。
结语：公平与效率的平衡术
expirationTime 模型不仅仅是 React 优化性能的技巧，它深刻地揭示了操作系统任务调度的本质：在资源有限的情况下，如何通过时间约束来换取公平性。
没有 expirationTime，React 就是一个独裁的暴君，只看谁按铃就先伺候谁，结果就是后排的客人永远吃不上饭。
有了 expirationTime，React 就变成了一位精明的经理。他不断看表，提醒那些拖延症晚期的任务：“喂！快点！超时了！现在立刻给我上菜！”
这种机制，让 JavaScript 这个单线程语言在处理复杂 UI 时，拥有了多线程般的“公平性”。下次当你觉得页面卡顿，或者某个功能莫名其妙延迟时，不妨想一想那个倒计时的 expirationTime，也许它正站在时间的尽头，等着拯救你的代码呢。
好了，今天的讲座就到这里。下课！记得回去多读两遍源码，那个 calculateExpirationTime 函数里藏着你意想不到的智慧！