各位同学，大家好！
欢迎来到今天这场名为“React 调度器：让浏览器喘口气的艺术”的深度技术讲座。我是你们的老朋友，一个在 React 源码里摸爬滚打了几年，头秃但依然对并发模式充满热情的资深工程师。
今天我们不谈业务逻辑，不谈怎么用 useState 或 useEffect，我们要聊聊 React 的“心脏”——也就是那个藏在 scheduler 包里的调度器。这是 React 18 引入并发模式的核心，也是让 React 从“传统的线性渲染”进化到“聪明的并发渲染”的秘密武器。
如果你觉得 React 只是渲染 UI，那你太小看它了。在 React 的世界里，它不仅要画图，还要像交通警察一样指挥浏览器的工作。如果它指挥不好，你的页面就会卡死；如果它指挥得太死板，用户体验就会极差。
所以，今天我们要探讨的核心议题就是：当高优先级任务（比如用户点击）和低优先级任务（比如后台数据同步）在同一个浏览器线程里相遇时，React 调度器是如何通过“时间切片”和“过期时间模型”来保护系统不被饿死，也不被撑死的？
准备好了吗？让我们把代码编辑器打开，把咖啡倒满，我们开始这场关于“时间”的冒险。
第一章：单线程的悲剧与救赎
首先，我们要明白一个残酷的事实：JavaScript 是单线程的。
这意味着什么？意味着你打开浏览器，浏览器只有一个主线程。这个线程就像是一个只有一张办公桌的忙碌收银员。所有的事情——解析 HTML、执行 JS、绘制画面、处理用户输入——都必须按顺序排队，一张接一张地处理。
想象一下，如果你是一个收银员（浏览器主线程），现在来了三个顾客：
- 顾客 A：只买一瓶水，扫码、付钱、走人。耗时 1秒。
- 顾客 B：买了满车的蔬菜，扫码、称重、找零、装袋，耗时 10秒。
- 顾客 C：也就是你，用户。你想看收银员扫码的过程，或者你想在这个时候把收银员叫走。
在传统的 React（React 17 及以前）模式下，收银员（主线程）会先处理完顾客 B（耗时 10秒），然后才能轮到顾客 C。在这 10 秒钟里，顾客 C 看到的页面是死寂的，收银员甚至可能因为忙不过来而崩溃。这就是阻塞。
而 React 18 的调度器要解决的就是这个问题。它要把那个“买了满车蔬菜的顾客 B”切成无数小块，每一小块只做一点点，然后停下来，把机会让给顾客 C（用户交互），等顾客 C 走了，收银员再回来继续切蔬菜。
这就是并发的本质。
第二章：优先级——谁才是老大？
在调度器里，任务不是平等的。有的任务火烧眉毛，必须马上做；有的任务可以缓一缓，甚至不做也行。
React 定义了一套严格的优先级体系，通常用数字 1 到 5 来表示，数字越小，优先级越高。
// 简化版的 React 优先级定义
const ImmediatePriority = 5; // 立即执行，最高优先级（例如用户点击）
const UserBlockingPriority = 4; // 用户阻塞级（例如正在输入）
const NormalPriority = 3; // 常规优先级（例如定时器触发）
const LowPriority = 2; // 低优先级（例如数据同步）
const IdlePriority = 1; // 空闲优先级（比如后台任务）但是，这还不够。React 还引入了一个更高级的概念叫 Lanes（车道）。Lanes 是基于二进制位的。
为什么用二进制？因为你可以组合优先级。
比如，用户点击是一个 Lane（Lane 1），数据同步是另一个 Lane（Lane 2）。如果一个任务既包含“用户点击”又包含“数据同步”，它就可以同时占用这两个 Lane。
这就像高速公路的收费系统。有的车道只允许跑车（高优先级），有的车道只允许大卡车（低优先级），有的车道是混合车道。调度器的工作就是决定当前应该让哪辆车走。
第三章：饥饿保护——别让低优先级任务饿死
好了，现在我们有了优先级。接下来我们面临一个经典的问题：饥饿。
什么是饥饿？
假设现在有 100 个任务排队：
- 前 99 个都是低优先级任务（比如计算斐波那契数列）。
- 第 100 个是高优先级任务（用户点击了“提交订单”）。
如果调度器是一个简单的“先进先出（FIFO）”队列，那么用户点击的信号会被卡在第 99 个任务后面整整跑完 99 个任务。用户会等得怀疑人生，觉得这个页面坏了。
调度器的解决方案：
调度器必须具备抢占机制。当高优先级任务到来时，必须打断当前正在运行的低优先级任务，让出主线程。
但是，这里有个问题：如果高优先级任务永远源源不断（比如用户疯狂点击），低优先级任务是不是永远没机会跑了？
是的，如果一直有高优先级任务，低优先级任务就会饿死。
React 的饥饿保护策略：
React 不会让低优先级任务永远饿死。它会设置一个截止时间。
具体来说，调度器会给每个任务分配一个 expirationTime（过期时间）。
公式大概是：expirationTime = currentTime + timeout。
- 高优先级任务：
timeout很短（比如 50ms）。这意味着：“你必须在 50ms 内完成，否则就算你过期了，老板（React）会直接把你扔进垃圾桶！” - 低优先级任务：
timeout很长（比如 5000ms）。这意味着：**“你慢慢做，你有 5 秒钟的时间。如果 5 秒后你还没做完，说明你太慢了，系统会自动丢弃你。”
这种机制既保证了高优先级任务的响应速度（因为它们有很短的截止时间，调度器会拼命赶它们），又保证了低优先级任务最终能得到执行机会（因为系统会定期检查，如果长时间没机会，就会强制运行它们）。
第四章：时间切片——切蛋糕的艺术
现在我们有了截止时间，接下来就是怎么切蛋糕了。
时间切片 是指将一个耗时的任务拆分成许多极小的片段，每个片段只执行很短的时间（通常是一帧，即 16ms）。
React 的调度器使用了浏览器的 requestIdleCallback（空闲回调）或者 requestAnimationFrame（动画帧）来实现这个功能。
核心逻辑演示
让我们写一段伪代码来模拟调度器是如何工作的。这段代码虽然简陋，但包含了 React 调度器的核心逻辑：检查时间、检查优先级、决定是否让出控制权。
// 模拟当前时间
let currentTime = 0;
// 模拟任务队列
const taskQueue = [
{ id: 1, priority: 3, duration: 1000, name: "计算斐波那契(高耗时)" }, // 低优先级，耗时长
{ id: 2, priority: 5, duration: 10, name: "用户点击(极短)" }, // 高优先级，耗时长
{ id: 3, priority: 2, duration: 2000, name: "数据同步(低优先级)" } // 极低优先级
];
// 1秒 = 1000ms
// 假设我们每帧执行的时间预算是 16ms (60FPS)
const frameBudget = 16;
function schedulerLoop() {
// 每次循环开始，更新当前时间
currentTime += frameBudget;
// 获取当前最高优先级的任务
// 注意：实际 React 源码中是用 Heap 优先队列维护的，这里简化为排序
const currentTask = getHighestPriorityTask();
if (!currentTask) {
console.log("没有任务了，浏览器可以休息了");
return;
}
console.log(`开始执行任务: ${currentTask.name} (优先级: ${currentTask.priority})`);
// 执行任务
// 模拟执行了 frameBudget 的时间
currentTask.duration -= frameBudget;
// --- 关键点：检查是否需要让出控制权 ---
// 1. 检查任务是否还没做完，且超过了当前帧的时间预算
const isTaskIncomplete = currentTask.duration > 0;
const hasTimeLeft = currentTime % frameBudget < frameBudget; // 简单的判断
if (isTaskIncomplete && hasTimeLeft) {
console.log(`任务 ${currentTask.name} 还没做完，但时间片到了。让出控制权给浏览器渲染下一帧。`);
// 这里 React 会调用 requestAnimationFrame 或 requestIdleCallback
// 下一帧再回来继续这个任务
requestNextFrame(() => schedulerLoop());
return;
}
// 2. 检查任务是否过期
// 在 React 中，我们会计算 expirationTime
const expirationTime = currentTime + 5000; // 假设低优先级任务 5秒过期
if (currentTime >= expirationTime) {
console.error(`任务 ${currentTask.name} 已过期！被丢弃。`);
// 移除任务
removeFromQueue(currentTask);
} else {
// 任务完成了
console.log(`任务 ${currentTask.name} 完成。`);
removeFromQueue(currentTask);
}
// 递归调用下一帧
requestNextFrame(() => schedulerLoop());
}
// 启动调度器
schedulerLoop();看懂了吗？这段代码就是 React 的灵魂。
当 schedulerLoop 运行时，它会拿走当前帧的 16ms。如果任务还没做完，它不会傻傻地继续跑，而是会停下来，告诉浏览器：“嘿，我要休息一下，你去画个图，渲染一下界面吧。” 这时候，用户就能看到界面动了，按钮也能被点击了。
这就是非阻塞。
第五章：过期时间模型——时间的残酷法则
刚才的代码里，我们提到了 expirationTime。这是 React 调度器中最具“冷酷逻辑”的部分。
什么是过期时间？
在 React 的源码中，每个任务都有一个 expirationTime 属性。这个值是相对于当前时间戳的。
计算公式：
// 简化版
function computeExpirationTime(currentTime, priorityLevel) {
// React 18 中，优先级越高，timeout 越短
// 比如 ImmediatePriority (5) 的 timeout 可能是 1ms
// 比如 IdlePriority (1) 的 timeout 可能是 5000ms
const timeout = getTimeoutForPriorityLevel(priorityLevel);
return currentTime + timeout;
}饥饿保护如何工作？
假设现在时间是 T=0。
- 任务 A（低优先级）：
expirationTime = 0 + 5000。 - 任务 B（高优先级）：
expirationTime = 0 + 50。
调度器开始工作。
- T=0 到 T=50：调度器处理高优先级任务 B。因为任务 B 必须在 50ms 内完成，所以调度器会拼命压榨 CPU，确保它完成。
- T=50：任务 B 完成了。调度器检查时间。
- T=50 到 T=5000：调度器开始处理低优先级任务 A。
如果任务 A 很慢怎么办？
假设任务 A 很笨重，计算量巨大。调度器切了 16ms，切了 16ms，切了 16ms…
到了 T=1000，任务 A 还没做完。
调度器会继续切，继续切…
到了 T=5000，任务 A 还没做完。
此时，React 会判断：currentTime (5000) >= expirationTime (5000)。
React 会认为任务 A 已经过期。
过期的后果是什么？
过期并不意味着任务 A 就彻底消失了，而是意味着 React 不再保护它了。
在 React 的并发渲染中，如果一个任务过期了，React 通常会采取以下策略之一：
- 丢弃它：如果是那种后台同步数据，过期了就直接扔掉，反正也没用户看。
- 降级处理：如果是渲染任务，过期了可能会降级为“非并发模式”执行，或者直接丢弃旧的更新，只保留最新的更新。
这就像一个赶去上班的迟到大王。如果他在 9:00 前没赶到，老板（React）就会认为他今天不用来了，直接开除。
这种机制极大地保护了用户体验。如果低优先级任务太慢，导致高优先级任务一直被阻塞，React 就会果断放弃那个慢任务，优先保证当前的高优先级交互（比如点击提交按钮）。
第六章：深入源码——runWithPriority 的魔法
让我们看看 React 源码中是如何封装这个逻辑的。在 packages/scheduler/src/Scheduler.js 中，有一个核心函数 runWithPriority。
它的作用就是：在执行某个函数时，临时改变当前的任务优先级，执行完后再恢复。
// 模拟 React 的 runWithPriority
function runWithPriority(priorityLevel, callback) {
// 1. 保存当前任务
const originalTask = currentTask;
const originalPriorityLevel = currentPriorityLevel;
// 2. 提升当前优先级
currentPriorityLevel = priorityLevel;
// 3. 计算新的过期时间
// 这一步非常关键，因为优先级变了，截止时间也要变
const expirationTime = computeExpirationTime(currentTime, priorityLevel);
// 4. 开始执行回调
try {
// 这里会调用任务循环
callback();
} finally {
// 5. 恢复现场
currentTask = originalTask;
currentPriorityLevel = originalPriorityLevel;
}
}实战场景：
当你点击一个按钮，触发一个 onClick 事件。
React 会调用 runWithPriority(UserBlockingPriority, () => { handleClick() })。
这意味着，在 handleClick 执行期间，即使后面来了一个“数据同步”的低优先级任务，调度器也会优先把控制权交给 handleClick。因为 UserBlockingPriority 的截止时间非常短，调度器会一直盯着它，直到它跑完。
这就解释了为什么 React 18 的点击响应比以前更灵敏。
第七章：Lanes——更细粒度的控制
刚才我们提到了优先级是 1-5。但在 React 18 中，Lanes 才是真正的王者。
Lanes 是一个 32 位的整数，每一位代表一种优先级。这就像一个开关阵列。
// React 内部定义的 Lane 枚举
const NoLanes = 0b00000000000000000000000000000000;
const SyncLane = 0b00000000000000000000000000000001; // 优先级 1
const InputContinuousLane = 0b00000000000000000000000000000010; // 优先级 2
const DefaultLane = 0b00000000000000000000000000000100; // 优先级 3
const TransitionLane = 0b00000000000000000000000000001000; // 优先级 4
const IdleLane = 0b00000000000000000000000000010000; // 优先级 5为什么要用 Lanes？
因为 React 需要处理混合优先级。
假设你正在输入文字（InputContinuousLane），同时后台开始同步数据（DefaultLane）。
React 怎么办？
它不能只选一个 Lane。它必须同时处理输入和同步。
React 使用了Lane 模型来进行合并和过滤。
- 合并：
newLanes = inputLanes | syncLanes。这表示同时有输入和同步任务。 - 过滤：
nextLanes = getHighestPriorityLane(newLanes)。这表示在所有任务中，找出优先级最高的那个 Lane。
在 Scheduler 模块中，虽然它不直接处理 Lanes（Lanes 是 Fiber 架构层面的），但 Scheduler 接收到的 priorityLevel 是从 Lanes 映射过来的。
这种设计非常巧妙，它允许 React 在一个渲染周期内，处理多种不同优先级的更新，而不需要启动多个独立的调度器实例。
第八章：调度器的“心跳”机制
最后，我们来聊聊 React 调度器是如何被触发的。它不会一直傻傻地跑，它需要“心跳”。
React 使用了两种机制来驱动调度器：
1. requestAnimationFrame (RAF)
RAF 会在每一帧（约 16ms）触发一次。
React 在渲染过程中，如果发现还有任务没做完，它会注册一个 RAF 回调。
如果浏览器在下一帧来了新的任务（比如用户点击了鼠标），React 会取消 RAF 回调，立即执行新任务。
2. MessageChannel (消息通道)
RAF 依赖于浏览器的刷新率。如果屏幕卡顿了（比如切换到后台），RAF 可能就不会触发。
为了保证可靠性，React 还会使用 MessageChannel 创建一个微任务队列。
当主线程忙完当前宏任务后，会检查是否有待处理的任务，如果有，就通过 MessageChannel 发送消息给调度器，唤醒它。
这就是为什么 React 即使在页面不可见时，也能保持响应。
第九章：实战演练——渲染百万级列表
现在，让我们把所有这些理论结合起来，看看它们是如何拯救一个“大列表渲染”场景的。
场景： 你有一个包含 100 万条数据的列表，需要渲染出来。用户想滚动列表。
没有调度器（React 17 模式）：
- React 开始遍历这 100 万条数据。
- 因为 JS 是单线程的，这 100 万条数据会占用主线程至少几秒钟。
- 在这几秒钟内，页面完全冻结。用户无法滚动，无法点击。
- 即使用户点击了“刷新”按钮，React 也听不见，因为它还在跑那 100 万条数据的循环。
有了调度器（React 18 模式）：
- React 开始遍历这 100 万条数据。
- 第 16ms：React 渲染了前 1000 条数据，发现时间到了。
- RAF 触发：React 停止工作，把控制权还给浏览器。
- 浏览器渲染：用户看到列表滚动到了第 1000 条，界面是流畅的。
- 用户点击：用户在滚动过程中点击了“刷新”。
- 抢占：调度器检测到这是一个高优先级任务（SyncLane/ImmediatePriority）。
- React 立即停止渲染那 100 万条数据，去执行刷新逻辑。
- 刷新逻辑执行完毕后，React 继续回来渲染那 100 万条数据。
结果：
用户感觉页面非常流畅，点击响应极快。虽然列表还是花了很久才完全渲染出来，但在渲染过程中，用户始终能控制页面。
这就是过期时间模型的功劳。如果刷新任务在渲染过程中一直被阻塞，它可能会过期，导致用户点击无效。但调度器通过抢占机制，确保了刷新任务始终能插队执行。
第十章：总结与反思
好了，同学们，今天的讲座接近尾声。
我们今天深入探讨了 React 调度器的两个核心支柱：调度与过期时间模型。
- 调度：它通过优先级队列和抢占机制，解决了单线程阻塞的问题。它让 React 有了“分身术”，可以在渲染的同时响应用户。
- 过期时间模型：它通过给任务设定截止时间，解决了任务饥饿的问题。它冷酷地丢弃过期任务，确保了系统始终有资源处理最新的、最重要的更新。
React 的调度器就像一个高明的交通指挥官。它不仅要疏导车流（渲染），还要考虑每辆车的时间紧迫性（过期时间），最重要的是，它必须确保每一辆车都有机会通过路口，哪怕它只是一辆慢吞吞的拖拉机（低优先级任务）。
写到这里，我不禁感叹 React 团队的伟大。他们没有引入一个庞大的操作系统内核，而是用几百行 JavaScript 代码，完美模拟了操作系统的进程调度算法。这就是工程艺术的极致。
最后，给大家留个作业：
下次当你写代码时，如果遇到 useEffect 里有一个耗时的循环，导致页面卡顿，不要急着优化算法。试着思考一下，是不是因为你的低优先级任务阻塞了高优先级任务？能不能把它拆分成一个个小任务，交给 React 的调度器去处理？
记住，在 React 的世界里，让出控制权往往比死磕到底更强大。
好了，今天的讲座就到这里。下课！记得去把你的 Scheduler 源码读一遍，你会发现很多乐趣。我们下次见！