各位前端大佬，各位（自称）的煮鸡（煮鸡即水煮鸡）……啊不对，各位未来的 React 大师们，大家好！
欢迎来到今天的“React 并发模式生死时速”特别讲座。我是你们的带课老师。
今天我们不聊怎么封装一个炫酷的弹窗，也不聊怎么把 Redux 拆成 six 个文件。今天我们要聊的是 React 的心脏——并发模式。我们要聊聊当你的浏览器主线程（那个可怜的单一 CPU 核心）正在努力搬砖的时候，React 是如何像一位老练的工地包工头一样，突然大喊一声“停！有人按了紧急按钮，去处理这个高优先级任务！”，然后把手里还没砌完的半截墙扔下，转头去修救火车。
这背后的逻辑，叫做“任务抢占”。听起来很高大上，对吧？其实就是如何在“我想一口气把页面渲染完”和“用户说他点的按钮太慢了我要急死你”之间寻找平衡。
准备好了吗？让我们把键盘敲烂，把服务器跑崩，进入源码的深渊。
一、 场景模拟：没有并发模式的“暴君”与并发模式的“外交官”
首先，我们要明白为什么我们需要并发。
以前，React 是个暴君。它说：“我要渲染这个页面，不管你在干嘛，不管你的手指在键盘上敲得有多快，我要把这一帧所有的 DOM 更新都做完，做完再给你看。”
如果页面上有 10,000 个节点要渲染，或者有个复杂的计算要跑，这会儿你的浏览器主线程就被 React 拿走了。这时候你按了个按钮，页面上那个该死的加载圈转得比蜗牛还慢，因为 CPU 还在给 React 搬砖呢。
并发模式是来干什么的？它是来当“外交官”的。它的目标是：在有限的时间内，尽可能把事情做完，一旦时间到了，或者遇到了更急的事儿，立刻把话筒递给更急的事儿。
这就涉及到了两个核心概念：Lane（车道） 和 Scheduler（调度器）。
二、 Lane：赛道上的赛道
我们怎么知道哪个任务急？怎么知道哪个任务可以等一会儿？
React 引入了一个叫 Lane 的东西。你可以把它理解成“车道”。赛车上，只有一条跑道，但我们可以给车道分等级。
在源码里，Lane 是一个整数，32位整数。32位能存多少东西？2的32次方。这够多了，我们用位运算来模拟赛道。
想象一下，你是个赛车手，面前有无限条车道。
- Lane 0 (SyncLane)：这是最快车道。就像救命稻草，用户刚输入的字符，必须是同步的，立马渲染，不能等。
- Lane 1 (InputContinuousLane)：这是高速车道。比如用户正在疯狂点击按钮。
- Lane 2 (IdleLane)：这是慢车道。比如一个在后台悄悄更新的数据。
当用户点击按钮时，这个点击事件会带上一个高优先级的 Lane（比如 Lane 1）。React 收到这个请求后，会决定：“好，现在我手头正在渲染 Lane 0 的任务（虽然可能刚开始），但我必须把 Lane 1 拿过来，插队！”
三、 Scheduler：那个催命的钟表
光有 Lane 还不够，我们需要一个机制来控制时间。这就是 scheduler 包（React 自带的小调度器）。
React 内部维护了一个 startTime 和一个 deadline。
主线程说：“我有 5 毫秒的时间干活（一帧的时间）。”
React 的 workLoop 逻辑大概是这个样子的（伪代码版）：
function workLoop() {
// 开始计时
const startTime = performance.now();
while (nextUnitOfWork) {
// 1. 执行当前节点的渲染工作
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
// 2. 关键时刻：检查时间到了吗？
// 如果当前时间 - 开始时间 > 5ms，说明这帧快完了
if (shouldYield(startTime)) {
// 3. 停！这里就是抢占的瞬间！
// 我们不结束了，而是返回，把控制权交还给浏览器，让浏览器画一下上一帧
return;
}
}
// 如果循环跑完了，恭喜，这次渲染任务完成了
root.finishedWork = current;
commitRoot();
}shouldYield 函数就是那个“老大哥”，它检查剩余时间。如果时间到了，它就告诉 React：“哥们，歇会儿吧，让别人也跑两步。”
四、 深度解剖：抢占是如何发生的？
现在，让我们深入源码，看看 performConcurrentWorkOnRoot 这个大杀器是如何处理“插队”的。
1. 插队请求的触发
当你在某个组件里调用了 setState，React 会把这个更新放入队列。它不是直接执行，而是先判断优先级。
如果这是一个高优先级更新（比如用户输入），React 会调用 scheduleUpdateOnFiber。
// 大致逻辑
function scheduleUpdateOnFiber(fiber, lane) {
// 检查当前正在渲染的优先级
// 如果当前渲染的 lane 比我要插入的这个 lane 优先级低，
// 那么我就必须中断当前渲染，重新开始！
if (lane !== NoLane && lane !== currentUpdateLane) {
// 这时候，React 会丢弃当前正在跑的 workInProgress，
// 重新分配 lanes，开启一轮新的渲染。
// 这就是“抢占”的信号。
}
}2. Fiber 树的“断点”
当 workLoop 因为 shouldYield 返回时，React 并不是什么都不干就结束了。它必须记住：“刚才我渲染到哪了？”
在 Fiber 架构中，每个节点都有指针：
return：指回父节点。sibling：指同级的兄弟节点。child：指子节点。
当我们在 performUnitOfWork 里遍历树的时候，如果我们停下来，nextUnitOfWork 指针就会指向那个“还没来得及渲染的兄弟节点”或者“父节点的下一个兄弟”。
源码里，你会看到这样的逻辑：
function performUnitOfWork(fiber) {
// 1. 给这个节点打标签，做 Diff 计算，创建新的 DOM
// (这部分代码非常长，涉及到 React Element 转换为 Fiber)
reconcileChildren(fiber, fiber.return, newChildren);
// 2. 执行完这个节点的副作用
executeSideEffects(fiber);
// 3. 找下一个要渲染的节点
if (fiber.sibling) {
return fiber.sibling; // 返回兄弟节点，继续
}
// 如果没有兄弟，返回父节点
fiber = fiber.return;
if (fiber) {
return fiber.sibling; // 如果父节点还有弟弟妹妹，返回它们
}
return null; // 整个树渲染完了
}这就是恢复的秘诀。
当高优先级任务中断后，主线程去处理高优先级任务（比如响应输入）。处理完后，主线程再次空闲，React 再次被唤醒。
它去哪里唤醒？它去 nextUnitOfWork 指向的地方！因为它之前已经记住了这个指针位置。
3. 源码级的“生死时刻”
让我们看看 React 源码中 react-reconciler 里的核心调度逻辑（简化版）：
function performConcurrentWorkOnRoot(root) {
// 初始化一些状态
const currentTime = getCurrentTime();
const expirationTime = computeExpirationForCurrentLanes(root);
// 这里的 workLoop 是我们的主角
// 注意：这个函数本身是可以被中断退出的
workLoopSync(root, expirationTime);
// workLoopSync 返回后，分两种情况：
if (root.finishedWork !== null) {
// 情况 A：渲染完了，开始提交阶段
commitRoot(root);
} else {
// 情况 B：时间到了，或者被中断了，我们放弃了
// 必须请求浏览器给点时间，或者检查是否有更急的任务
if (!isWorkerRunning) {
// 请求下一帧
requestWork(root, expirationTime);
}
}
}
function workLoopSync(root, expirationTime) {
// 这里的 workLoop 不是真正的并发，是同步的，用于初始化
// 但如果是真正的并发，我们要用 workLoopConcurrent
// ...
}真正的并发逻辑在 workLoopConcurrent 中：
function workLoopConcurrent(root) {
// 防止死循环，设个开关
// isWorkerRunning = true;
// 核心：while 循环，但里面藏着定时器检查
while (nextUnitOfWork !== null && !shouldYieldToHost()) {
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
}
// isWorkerRunning = false;
}这里的关键是 shouldYieldToHost()。这个函数实际上是调用了 scheduler 包里的 shouldYield。
// React 源码中类似的实现
function shouldYieldToHost() {
const currentTime = getCurrentTime();
const timeElapsed = currentTime - startTime;
// 如果超过 5ms (或者更复杂的帧时间计算)，就返回 true
if (timeElapsed >= frameDeadline) {
// 处理过帧的情况，虽然不理想，但保命要紧
frameDeadline += 5;
return true;
}
// 还没超时，允许继续跑
return false;
}五、 高优先级 Lane 如何“暴力”接管
好，现在我们把镜头拉近。假设你正在渲染一个巨大的列表，每个列表项需要 0.1ms 的计算量。
时间 T0： React 开始渲染。分配了 SyncLane（Lane 0）。
时间 T1（0.5ms）： 你正在渲染第 500 个列表项。
时间 T2（0.6ms）： 此时，用户按下了一个非常关键的“提交订单”按钮！这个按钮的优先级是 InputContinuousLane（Lane 1）。
在 React 内部，updateContainer 会检测到这个新请求。
// 简化的调度逻辑
function scheduleUpdateOnFiber(fiber, lane) {
// 假设当前正在渲染的是 NoLane (或者更低优先级的 lane)
// 且新 lane 是 InputContinuousLane
if (lane !== NoLane && lane > currentRenderLanePriority) {
// 糟糕，高优先级插队了！
// 1. 暂停当前任务
// 我们通过打断 workLoop 来实现。
// 在源码里，这会设置一个标志位，或者直接抛出一个异常（虽然不是真的 throw），
// 告诉主线程：“兄弟，别干了，去处理这个新任务。”
// 2. 丢弃旧的 workInProgress 树
// 之前的渲染白费了。React 会把 `workInProgress` 指向 null，
// 把 `current` 指针重新指回来（或者保持，视情况而定，但渲染树会重建）。
// 3. 重新开始渲染
// 重新调用 performConcurrentWorkOnRoot，这次带着 InputContinuousLane。
}
}这就是所谓的“暂停”和“丢弃”。由于 CPU 是单线程的，如果当前正在渲染第 500 个节点，React 必须把之前渲染的 500 个节点的状态全部“遗忘”或者“保存”到 current 树上（Commit 阶段会做这个），然后从第 0 个节点或者第 1 个节点开始重新跑。
这就是代价。抢占是有成本的。
六、 恢复执行：把断掉的线接上
这是最神奇的部分。高优先级任务跑完了，轮到低优先级任务继续，它怎么知道从哪接？
还记得我们的 performUnitOfWork 吗？它返回 nextUnitOfWork。
// 当我们被中断时，nextUnitOfWork 指向的是那个“未完成的兄弟节点”
// 比如：Parent -> [ChildA (finished), ChildB (interrupted), ChildC]
function performUnitOfWork(fiber) {
// ... 做完 ChildA 的活 ...
// ... 找到了 ChildB，还没做 ...
// 此时 nextUnitOfWork = ChildB;
// 函数返回，进入 `shouldYield` 逻辑，中断循环。
}
// 当时间片再次到来，或者任务被调度回来时
function workLoopConcurrent(root) {
// 此时 nextUnitOfWork 依然指向 ChildB
while (nextUnitOfWork) {
// 直接从 ChildB 开始执行！
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
// ... 接着做 ChildB，然后是 ChildC ...
}
}这种机制类似于汇编语言的“栈帧”。React 并不是真的把整个栈保存下来，而是通过 Fiber 树的指针关系，巧妙地利用了递归调用栈的返回特性。
七、 代码示例：手写一个微缩版的 React 抢占逻辑
为了证明我是个靠谱的讲师，我们用 TypeScript 写一个极度简化版的并发渲染器。别被吓跑，这只有 50 行代码，但包含了核心逻辑。
// 模拟时间片
let deadline: number = 0;
let isYielding: boolean = false;
// 模拟 Lane 优先级
enum Lane {
Low = 0,
High = 1 << 1, // 2
Sync = 1 << 0, // 1
}
// 模拟 Fiber 节点
interface FiberNode {
id: number;
lane: Lane;
next: FiberNode | null;
}
// 模拟当前正在渲染的任务队列
let currentTask: FiberNode | null = null;
let nextTask: FiberNode | null = null;
// 模拟 Scheduler 的 shouldYield
function shouldYield(): boolean {
const now = performance.now();
if (now >= deadline) {
isYielding = true;
return true;
}
isYielding = false;
return false;
}
// 核心工作单元：执行一个节点
function performUnitOfWork(node: FiberNode) {
console.log(`正在渲染节点: ${node.id}, 优先级: ${node.lane}`);
// 模拟耗时操作
const start = performance.now();
while (performance.now() - start < 5) {
// 忙碌等待，模拟计算
}
// 渲染结束，返回下一个任务
// 简单的扁平化队列模拟
if (node.next) {
return node.next;
}
return null;
}
// 模拟 React 的调度器
function scheduleRoot(task: FiberNode, priority: Lane) {
console.log(`[调度器] 接收到新任务，优先级: ${priority}`);
// 如果当前没有任务，直接开始
if (!currentTask) {
currentTask = task;
nextTask = task;
requestIdleCallback(workLoop);
}
// 如果有任务，且新任务优先级高于当前任务（这里简化逻辑，实际有更复杂的 Lane 比较）
else if (priority > Lane.Low) {
console.log(`[调度器] 检测到高优先级任务，准备抢占！`);
// 丢弃当前任务，抢占执行
currentTask = task;
nextTask = task;
}
}
// 模拟 requestIdleCallback
function requestIdleCallback(callback: () => void) {
deadline = performance.now() + 10; // 假设每帧给 10ms
callback();
}
// 模拟 WorkLoop
function workLoop() {
// 如果没有任务了，或者被标记为中断了，就结束
if (!nextTask) return;
// 只有当没有正在中断且时间允许时才继续
if (isYielding) {
console.log("WorkLoop 中断，将控制权交还给浏览器...");
// 请求下一帧继续
requestIdleCallback(workLoop);
return;
}
// 执行当前任务
const node = nextTask;
currentTask = node;
nextTask = performUnitOfWork(node);
// 检查是否需要抢占（通过时间片）
if (shouldYield()) {
// 在这里，我们成功实现了中断！
// 下次 requestIdleCallback 回来时，nextTask 依然是当前未完成的节点
// performUnitOfWork 返回的值，保证了恢复执行的正确性
} else {
// 继续执行直到任务结束
requestIdleCallback(workLoop);
}
}
// --- 演示开始 ---
console.log("--- 模拟场景 ---");
// 1. 启动一个低优先级任务（渲染一个巨大的列表）
const lowPriorityTask: FiberNode = {
id: 1,
lane: Lane.Low,
next: { id: 2, lane: Lane.Low, next: null } as any
};
scheduleRoot(lowPriorityTask, Lane.Low);
// 延迟一点，启动一个高优先级任务（用户点击）
setTimeout(() => {
console.log("n[时间流逝] 用户点击了按钮！");
const highPriorityTask: FiberNode = {
id: 100,
lane: Lane.High,
next: null
};
scheduleRoot(highPriorityTask, Lane.High);
}, 20);
这段代码展示了：
- ScheduleRoot：判断优先级，决定是否抢占。
- WorkLoop：循环执行任务。
- ShouldYield：检查时间，决定是否中断。
- NextTask：中断后，利用
nextTask的状态实现恢复。
八、 提交阶段：被遗忘的节点们
等高优先级的任务渲染完了，React 会进入 commitRoot 阶段。这时候，所有的 DOM 变更都会一次性应用到页面上。
此时，workInProgress 树变成了新的 current 树。之前被高优先级任务“打断”而没来得及渲染的节点，它们的 alternate 属性（也就是之前在内存中没完成的那个备份）会被合并或者丢弃。
这就像你写文章写到一半被打断了，你把草稿扔进垃圾桶（或者保留在内存中），然后重新写了一篇新文章。最后，你把新文章贴到墙上。如果新文章没写完，墙上的部分还是旧的。
九、 总结与升华
各位，讲了这么多，React 并发模式的任务抢占逻辑到底是什么？
它就是一种优雅的博弈。
CPU 是唯一的，它是霸主。React 是侍卫。Lane 是等级。Scheduler 是发令枪。
当侍卫（React）正在用单核 CPU（浏览器主线程）完成一项繁琐的宫殿建设（低优先级渲染）时，国王（用户）突然喊了一声“救命！”（高优先级交互）。侍卫不能装作没听见，他必须立刻放下手里的砖头，冲过去处理国王的事。处理完后，他回到原地，继续砌墙。虽然墙可能砌歪了一点点（因为重新分配了 Lane），甚至之前的进度白费了（时间片浪费），但他保住了国王的命，也保住了宫殿——虽然只是暂时的。
这就是 performConcurrentWorkOnRoot 带给我们的震撼。它让我们明白，“不立即反馈”并不总是坏事。只要我们有一个健壮的中断和恢复机制，慢一点，反而是为了更快地响应用户的核心需求。
希望今天的源码分析能让你下次看到 Suspense 或 useTransition 时，不再是看着那个旋转的圈圈发呆，而是能在脑海里构建出那一个个在时间缝隙中穿梭的 Fiber 节点，看着它们为了你的用户体验而拼命跑圈。
下课！记得改代码！