各位好，欢迎来到今天的“React 内部架构深度解剖”特别讲座。我是你们的老朋友，那个总是喜欢在代码里挖坑然后自己跳进去填坑的资深工程师。
今天我们要聊的话题有点硬核，甚至有点枯燥——如果我不加料的话。我们要聊的是 React 的稳定性保证：expirationTime 防止任务饥饿。
听到“任务饥饿”这个词，你们是不是觉得饿了？别急，我们先吃个面包，然后咱们来聊聊为什么你的 React 应用有时候会像个得了帕金森的老人，手指头在键盘上乱抖，但屏幕上的数字就是不动。
第一章：调度器是个什么鬼？
在 React 16 之前，如果我们要更新 DOM，那简直就是一场“核爆”。为什么？因为它是同步的。
想象一下，你正在玩一个超级复杂的 3D 游戏，突然屏幕卡住了 3 秒钟，因为游戏引擎正在重新计算所有的几何体。在 React 里，这就是 setState。
代码示例 1：同步渲染的噩梦
// 假设这是 React 15 的世界
function App() {
const [count, setCount] = useState(0);
const handleClick = () => {
console.log('用户点击了按钮');
// 这是一个同步调用
setCount(prev => prev + 1);
setCount(prev => prev + 1);
setCount(prev => prev + 1);
// 这里的 DOM 更新是阻塞的！
console.log('DOM 更新完成了，点击事件结束了');
};
return <button onClick={handleClick}>点我</button>;
}如果你点击了 100 次按钮，React 就会像一辆失控的赛车，连续跑完 100 圈。浏览器窗口会卡死，用户会觉得你的应用坏了。这就是“任务饥饿”的雏形——用户的交互（点击）被巨大的计算任务（渲染）给“饿”死了。
为了解决这个问题，React 团队引入了 Scheduler（调度器）。Scheduler 的任务就是把那些大的渲染任务切成小块，像切香肠一样，吃一口，喘口气，再吃一口。这样，用户的点击事件（高优先级）就能插队进来，得到及时响应。
第二章：ExpirationTime —— 时间截止线
现在，我们有了 Scheduler，有了时间切片。但问题来了：Scheduler 怎么知道什么时候该“喘口气”了？如果 Scheduler 太仁慈，把所有任务都切得细碎无比，那渲染速度也太慢了，用户体验也不好。
这时候，ExpirationTime（过期时间） 登场了。它就像是一个严厉的老板，给每个任务设定了一个“死线”。
ExpirationTime 是一个时间戳，它表示“这个任务必须在什么时候之前完成”。如果时间到了任务还没做完，React 就会强行把它挤出去，或者给它一个更高的优先级来确保它不被饿死。
核心逻辑：
- 高优先级任务（比如用户点击）： 过期时间很短（比如 5ms）。这意味着它必须在 5ms 内完成，否则就“过期”了。
- 低优先级任务（比如后台数据计算）： 过期时间很长（比如 500ms）。它可以在后台慢慢磨。
第三章：源码深潜 —— 计算过期时间
让我们打开 React 的源码（简化版），看看这个“死线”是怎么算出来的。
// 模拟 React 的 Scheduler 源码逻辑
const now = () => performance.now();
// 优先级映射
const PriorityLevels = {
NoPriority: 0,
ImmediatePriority: 1,
UserBlockingPriority: 2, // 用户交互
NormalPriority: 3, // 普通渲染
LowPriority: 4, // 后台任务
IdlePriority: 5 // 空闲时
};
// 计算过期时间的核心函数
function computeExpirationForPriority(priorityLevel) {
// 我们有一个基准时间，假设是 0
const currentTime = now();
// 根据优先级，我们返回一个过期时间戳
// 优先级越高，返回的时间戳离现在越近（截止越早）
switch (priorityLevel) {
case PriorityLevels.ImmediatePriority:
// 立即执行，过期时间就是当前时间 + 1ms
return currentTime + 1;
case PriorityLevels.UserBlockingPriority:
// 用户交互，给一点缓冲，比如 250ms
// 如果超过 250ms 用户还在操作，那说明系统卡死了
return currentTime + 250;
case PriorityLevels.NormalPriority:
// 普通渲染，给 5000ms
return currentTime + 5000;
case PriorityLevels.LowPriority:
// 低优先级，给 10000ms
return currentTime + 10000;
case PriorityLevels.IdlePriority:
// 空闲优先级，永远不强制过期（除非浏览器关了）
return NoExpiration;
}
}看懂了吗？这就是数学的魔力。computeExpirationForPriority 就像是一个算命先生，根据任务的“性格”（优先级），算出它能活多久。
第四章：任务饥饿的救星 —— ShouldYield
有了过期时间，Scheduler 还需要一个机制来检查时间。这个机制叫 shouldYield()。
每当 Scheduler 跑完一小段代码，它都会问浏览器：“嘿，兄弟，现在几点了？”
function workLoop() {
// 1. 获取当前时间
const currentTime = now();
// 2. 检查当前正在执行的任务是否“过期”了
// 如果当前时间 > 任务截止时间，说明这个任务已经超时了！
while (workInProgress !== null && currentTime <= currentExpirationTime) {
// 执行任务
performUnitOfWork(workInProgress);
// 更新时间
currentTime = now();
}
// 3. 关键的一步：检查浏览器是否空闲
// 如果任务没做完，但浏览器正在忙别的（比如处理点击事件），那我们就停一下
if (currentTime <= currentExpirationTime) {
// 如果任务还没过期，但我们忙完了，那就让出主线程
return null;
}
// 如果任务过期了，或者浏览器空闲，继续干活
return true;
}场景模拟：
假设你现在正在渲染一个包含 10,000 个列表项的页面。这是一个低优先级任务，它的 expirationTime 是 5000ms 后。
- T = 0ms: 你点击了输入框，想输入文字。这是一个高优先级任务，
expirationTime是 250ms 后。 - T = 1ms: React 的 Scheduler 发现输入框的更新比渲染列表更紧急。
- T = 10ms: 渲染列表的任务切了一刀，跑完了 10ms，执行了
shouldYield()。 - T = 11ms: 浏览器处理了你的输入，输入框显示了你打出的字。
- T = 100ms: 浏览器处理完了输入，轮到 Scheduler 回来了。它一看：“哦，当前时间 100ms，离列表的截止时间 5000ms 还远着呢，继续渲染。”
- T = 300ms: 渲染列表的任务切了第二刀。
- T = 260ms: 此时，用户又点击了一下按钮。这个新任务的高优先级
expirationTime是 250ms。 - T = 261ms: Scheduler 被唤醒。它检查当前时间（261ms）是否超过了新任务的截止时间（250ms）。是的！
- 结果：渲染列表的任务被“饿”死了（或者被暂停了），新任务插队成功。
这就是 expirationTime 的核心作用：它定义了任务的生死线。
第五章：为什么我们需要 Fiber？
你可能会问：“老哥，直接用 setTimeout 不行吗？”
当然可以，但是 setTimeout 是“宏任务”，它的精度很差，而且由浏览器主线程调度，React 很难控制。React 需要的是“微任务”级别的精确控制。
于是，React 团队发明了 Fiber 架构。
Fiber 不仅仅是一个数据结构（链表），它是一个执行单元。
代码示例 2：Fiber 节点与过期时间的绑定
// FiberNode 的简化定义
class FiberNode {
constructor(tag, pendingProps, expirationTime) {
this.tag = tag; // 比如函数组件、宿主组件等
this.pendingProps = pendingProps;
this.expirationTime = expirationTime; // 关键！每个节点都有自己的过期时间
// 指向下一个兄弟节点
this.sibling = null;
// 指向父节点
this.return = null;
}
}
// 创建一个低优先级任务
function createLowPriorityWork() {
// 假设当前时间 1000ms
const currentTime = 1000;
// 低优先级任务的过期时间是 10000ms 后
const expirationTime = currentTime + 10000;
return new FiberNode('LowPriorityWork', null, expirationTime);
}
// 创建一个高优先级任务
function createHighPriorityWork() {
const currentTime = 1000;
// 高优先级任务的过期时间是 250ms 后
const expirationTime = currentTime + 250;
return new FiberNode('HighPriorityWork', null, expirationTime);
}当 React 遍历 Fiber 树时，它会按照 expirationTime 从小到大（即从高优先级到低优先级）进行排序。
// 简单的遍历逻辑
function traverseFiberTree(root) {
let node = root;
let stack = [node];
while (stack.length > 0) {
const current = stack.pop();
// 1. 检查当前节点是否过期
if (now() > current.expirationTime) {
console.warn(`任务 ${current.tag} 已经过期了！必须立即执行！`);
// 强制执行逻辑...
} else {
// 2. 没过期，继续遍历子节点
if (current.child) stack.push(current.child);
if (current.sibling) stack.push(current.sibling);
}
}
}第六章：优先级的“阶级社会”
React 内部其实是一个等级森严的社会。
- IdlePriority (空闲优先级): 没人管的时候干点轻活，比如分析代码，或者做一些对性能影响极小的工作。
- LowPriority (低优先级): 比如更新那些不可见的 Tab 页内容，或者执行一些不重要的动画。
- NormalPriority (普通优先级): 这是 React 的默认行为。比如你点击了一个按钮，页面更新。如果这个更新不复杂，就用这个。
- UserBlockingPriority (用户阻塞优先级): 这是最重要的。当用户正在交互（打字、拖拽、滚动）时，React 必须确保这些操作不被卡顿。如果发现交互动作导致 React 没法响应，React 会瞬间把优先级提升到这个级别。
- ImmediatePriority (立即优先级): 最高级别。比如在组件挂载时，或者某些生命周期函数中。这就像是把车开到了最高档，不管路况如何，必须立刻通过。
代码示例 3：Priority 的动态调整
React 18 引入了 startTransition，这是一个非常高级的功能，它允许我们将一个更新标记为“低优先级”，从而防止它阻塞高优先级的更新。
import { startTransition, useState } from 'react';
export default function App() {
const [input, setInput] = useState('');
const [count, setCount] = useState(0);
// 这是一个普通的输入框
const handleChange = (e) => {
// 原来的写法：普通优先级
// setInput(e.target.value);
// 新写法：低优先级
// 即使这里的数据量很大（比如几万个字符），也不会卡住 UI
startTransition(() => {
setInput(e.target.value);
});
};
// 这是一个高优先级更新
const handleClick = () => {
setCount(c => c + 1);
};
return (
<div>
<input value={input} onChange={handleChange} />
<button onClick={handleClick}>Count: {count}</button>
</div>
);
}在这个例子中，input 的更新被标记为低优先级。当用户疯狂打字时，handleChange 会触发很多次 startTransition。React 会把这些更新收集起来，如果用户还在打字，React 就会继续处理输入的响应，而不是去计算 input 的值。
第七章：ExpirationTime 的边界情况
虽然 expirationTime 很好，但如果不小心，它也会带来副作用。
问题 1：视觉闪烁
如果一个低优先级的任务（比如重绘背景）突然被提升为高优先级（因为过期了），可能会导致画面闪烁。这就像你正在吃慢炖的牛肉，突然有人端上来一盘热腾腾的炒饭，你不得不先吃炒饭。
问题 2：时间切片的代价
为了防止饥饿，React 必须频繁地打断渲染。这会导致大量的垃圾回收（GC）压力，因为每次打断都会产生新的 Fiber 节点。如果任务切得太碎，CPU 的开销反而比一次干完还大。
代码示例 4：处理过期的策略
React 在源码中有一个非常有趣的逻辑，叫做 requestPaint。
function performUnitOfWork(workInProgress) {
// ... 执行一些工作 ...
// 检查是否过期
if (workInProgress.expirationTime <= now()) {
// 如果过期了，我们需要给浏览器一个提示，告诉它“赶紧画！”
// 因为 requestIdleCallback 可能不会在过期的一瞬间被调用
requestPaint();
}
// 继续下一步
}第八章：真实世界的“饥饿”案例
让我们看一个真实的场景，如果你的代码写得烂，expirationTime 就会失效。
场景：在 useEffect 里做繁重的计算
useEffect(() => {
// 这是一个致命的陷阱！
// 这个副作用没有指定依赖数组，而且包含了繁重计算
const heavyCalculation = () => {
let sum = 0;
for (let i = 0; i < 1000000000; i++) {
sum += i;
}
return sum;
};
const result = heavyCalculation();
console.log(result);
}, []); // 空依赖数组React 会把这个 useEffect 当作一个任务。由于它没有依赖项变化，React 可能会把它标记为低优先级（或者缓存起来，只有在内存紧张时才执行）。
如果此时用户点击了页面上的按钮，触发了一个高优先级的 setState。React 会有两种处理方式：
- 丢弃 Effect：React 为了响应按钮点击，直接跳过了这个耗时的 Effect，导致副作用没有执行。这虽然解决了饥饿，但可能不是你想要的结果。
- 等待 Effect 完成：React 优先执行 Effect。那么，用户的点击会被阻塞。这就是任务饥饿。
解决方案：使用 useDeferredValue 或者手动将任务拆分。
// 正确的做法：拆分任务
useEffect(() => {
let cancelled = false;
const doWork = async () => {
const result = await heavyCalculation();
if (!cancelled) {
console.log(result);
}
};
doWork();
return () => {
cancelled = true; // 清理函数，防止任务完成后更新已卸载的组件
};
}, []);第九章：React 18 的并发模式与 ExpirationTime
React 18 引入了 useTransition 和 startTransition，本质上是对 expirationTime 机制的一种更高级的封装。
以前，expirationTime 是一个“硬”时间限制。现在，React 引入了“暂停”和“恢复”的概念。
你可以在代码中显式地告诉 React：“嘿，这个任务虽然重要，但如果用户正在打字，你就先别动它，把它放到后台去。”
import { useTransition } from 'react';
export default function SearchApp() {
const [isPending, startTransition] = useTransition();
const [query, setQuery] = useState('');
const [results, setResults] = useState([]);
const handleChange = (e) => {
const value = e.target.value;
setQuery(value);
// startTransition 将更新标记为低优先级
startTransition(() => {
// 这里计算结果非常耗时
const newResults = expensiveSearch(value);
setResults(newResults);
});
};
return (
<>
<input value={query} onChange={handleChange} />
{isPending ? <div>Loading...</div> : <List items={results} />}
</>
);
}在这个例子中，query 的更新是高优先级的（输入框必须立刻响应），而 results 的更新是低优先级的（列表可以晚一点显示）。React 的调度器会根据 expirationTime 自动管理这两者的优先级，确保输入框不卡顿。
第十章：ExpirationTime 的数学之美
让我们再深入一点，看看 React 是如何计算这个“死线”的。
在 React 源码中，有一个 computeInteractiveExpiration 函数，它基于当前时间加上一个动态的延迟。
function computeInteractiveExpiration(currentTime) {
// 用户交互的过期时间通常很短
// 如果超过这个时间还没响应，用户就会觉得卡
return currentTime + 50; // 50ms
}React 还有一个 computeTimestampExpiration，用于处理普通的渲染。
function computeTimestampExpiration(currentTime) {
// 这是一个基于时间片的计算
// 每个时间片是 5ms
// 我们希望在一个时间片内完成一个任务，或者切分成多个时间片
return currentTime + 5000;
}有趣的是，React 会根据任务的类型动态调整 expirationTime。如果一个任务已经运行了一半，React 可能会延长它的 expirationTime，给它更多的时间来完成，而不是直接扔掉。这体现了 React 的“宽容性”。
第十一章：如何防止任务饥饿（最佳实践）
作为资深工程师，我们如何利用 expirationTime 的原理来编写更好的代码？
-
避免在同步代码中做繁重计算：
不要在render函数或者事件处理函数的主线程里写死循环。把计算任务扔到setTimeout或者 Web Worker 里。 -
合理使用
useTransition：
对于那些不影响当前视图核心逻辑的数据更新，使用startTransition。这实际上是在告诉 React：“把这个任务的expirationTime设得高一点（即截止得晚一点）”。 -
利用
useDeferredValue：
当你需要展示一个可能会变动的长列表或大数据集时，使用useDeferredValue。它会自动将值的更新降级为低优先级。
const deferredQuery = useDeferredValue(query);
return (
<>
<input value={query} onChange={e => setQuery(e.target.value)} />
<List items={deferredQuery} /> {/* 这里的列表更新是低优先级的 */}
</>
);- 理解副作用：
useEffect的执行时机是可预测的，但它的优先级可能不是你想要的。确保你的副作用不会阻塞主线程。
第十二章：总结与展望
好了，各位同学，今天的讲座接近尾声。
我们聊了 React 的“后台调度员”——Scheduler。
我们聊了它的“死亡通知书”——ExpirationTime。
我们聊了如何防止“任务饥饿”，让用户的点击永远比后台的渲染快一步。
ExpirationTime 不仅仅是一个数字，它是 React 为了保证用户体验而建立的一道防线。它强制要求 React 在“做正确的事”（渲染）和“做及时的事”（响应）之间找到平衡点。
在这个数据爆炸、交互复杂的时代，React 通过 Fiber 和 ExpirationTime 构建了一个极其复杂的调度系统。它像是一个精密的瑞士钟表，每一个齿轮（Fiber 节点）都有它的时间刻度（ExpirationTime），每一颗螺丝（调度逻辑）都在为了那个“不卡顿”的目标而转动。
下次当你点击按钮，看到界面流畅地响应时，不要只觉得这是“理所当然”。你应该在心里默默感谢那个隐藏在代码深处的 Scheduler，感谢它严格执行了 expirationTime，感谢它没有让那个耗时的任务把你饿死。
记住，优秀的代码不仅要能跑通，还要能“懂事”。而 React 的调度机制，就是它最大的“懂事”之处。
谢谢大家，下课！