React 协调器中的脏检查机制：探究 checkScheduledUpdateOnFiber 如何自下而上标记更新路径

各位同学，大家下午好！

欢迎来到今天的“React 源码深度解析”现场。我是你们的讲师，一个在 React 代码里摸爬滚打多年的“老司机”。今天我们不聊 Hello World，也不聊 Hooks 的花式写法，我们要聊聊 React 协调器里一个稍微有点“晦涩”，但又是整个性能优化的基石——脏检查机制。

特别是那个大名鼎鼎的函数：checkScheduledUpdateOnFiber。

听到“脏检查”这四个字，大家脑海里可能浮现出 jQuery 时代的 $(this).addClass('dirty')，或者是 Angular 那种每帧都跑一遍全量 diff 的疯狂。但 React 不是那样的。React 是优雅的，它是基于优先级的调度大师。然而，在这个优雅的大师袍子下面，藏着一条极其精密的“自下而上”的标记路径。今天，我们就来扒开这条路径，看看 React 到底是怎么知道“谁脏了”的。

一、 场景重现：一场并不存在的家庭作业

为了讲清楚 checkScheduledUpdateOnFiber，我们先构建一个场景。

假设我们有一个典型的 React 组件树，长得像这样：

function GrandParent() {
  console.log("GrandParent 渲染了");
  return (
    <Parent>
      <Child />
    </Parent>
  );
}

function Parent({ children }) {
  console.log("Parent 渲染了");
  return <div>{children}</div>;
}

function Child() {
  const [count, setCount] = useState(0);
  console.log("Child 渲染了");

  return (
    <button onClick={() => setCount(c => c + 1)}>
      Count is {count}
    </button>
  );
}

现在，用户点击了 Child 组件里的按钮。

在 React 的世界里，这不仅仅是一次点击。这是一场调度事件。React 协调器（Scheduler）首先会介入，决定“现在”或者“下一帧”谁来干活。假设协调器决定让 GrandParent 开始工作。

这时候，GrandParent 也就是根节点，开始执行 beginWork。

beginWork 是个递归函数，它会像探雷一样，从根节点开始，往下找它的子节点。

1. 它先到 Parent。
2. 再到 Child。

当 beginWork 到达 Child 时，它发现：“哦豁，Child 的更新队列里有东西！”

这时候，checkScheduledUpdateOnFiber 就闪亮登场了。它就像是一个尽职的保安，站在 Child 的门口，问它：“嘿，兄弟，你这儿有活儿要干吗？”

Child 说：“有啊，我刚被点了，有更新。”
保安点点头，然后转头看向它的父节点 Parent，问：“那你父节点呢？它知道你脏了吗？”

这就是自下而上标记的核心逻辑。React 不会盲目地让所有爷爷辈都重新渲染，它得一层层往上确认。

二、 checkScheduledUpdateOnFiber 的源码剖析

我们打开 ReactFiberWorkLoop.js（这是 React 17/18 的核心文件），找到这个函数。它的代码看起来很简单，但充满了深意：

function checkScheduledUpdateOnFiber(fiber, renderExpirationTime) {
  // 1. 获取当前 Fiber 的更新队列
  const updateQueue = fiber.updateQueue;

  // 2. 如果更新队列不为空，说明这个 Fiber 上有待处理的更新
  if (updateQueue !== null) {
    // 这里的逻辑稍微有点绕，我们分两步走：
    // 第一步：检查是否有更新过期了（或者有更新尚未处理）
    // 第二步：检查是否有来自子节点的更新（即“自下而上”的标记）

    // 注意：在旧版本中，我们直接看 fiber.expirationTime。
    // 在新版本中，逻辑更复杂，涉及到 lanes 和 expirationTime 的转换。
    // 但为了理解“脏检查”的本质，我们看这个核心判断：

    const lastRenderedLane = updateQueue.lanes;

    // 如果这个 Fiber 的渲染优先级（expirationTime）大于当前正在进行的渲染优先级
    // 那么说明这个 Fiber “脏”了，需要被标记。
    if (fiber.expirationTime > renderExpirationTime) {
      // 标记自己为需要更新的状态
      // 这里的标记通常是通过设置 fiber.expirationTime 或者更新 lanes 来完成的
      // 比如：fiber.expirationTime = renderExpirationTime;
    }
  }

  // 关键点来了：如果当前 Fiber 没有更新，但它的子 Fiber 有更新...
  // React 怎么知道？
  // 因为 beginWork 的递归特性！
}

看懂了吗？这个函数的核心不在于它“检查”了什么，而在于它触发了什么。

当 beginWork 从 Child 往上走到 Parent 时，它会在 Parent 这个节点上也调用一次 checkScheduledUpdateOnFiber。

这时候，Parent 会检查自己的 updateQueue。如果 Parent 没有直接的用户交互，它的 updateQueue 可能是空的。但是，React 的设计非常精妙：子节点的更新队列，是会“继承”并“合并”到父节点的更新队列里的。

这就好比孩子考了 100 分（Child 更新），家长（Parent）的“家庭作业记录本”（updateQueue）上也会被记上一笔。

三、 深度解析：自下而上的“传话游戏”

让我们模拟一下内存中的状态变化，这比看代码更直观。

阶段 1：Root 开始工作

协调器告诉 Root：“嘿，老兄，开始干活吧！”

function performSyncWorkOnRoot(root) {
  // root.current 是当前屏幕上显示的那个 Fiber 节点
  const workInProgress = root.current;
  // 开始递归
  workInProgress = beginWork(workInProgress, renderExpirationTime);
}

阶段 2：Child 脏了

当递归走到 Child 时，用户点击了按钮。dispatchSetState 被调用。

function dispatchSetState(fiber, queue, action) {
  // 1. 创建一个 update 对象
  const update = { action, next: null };

  // 2. 把 update 放入队列
  enqueueUpdate(queue, update);

  // 3. 标记 Fiber 的过期时间
  // 这里是关键！Child 现在变“脏”了，它的 expirationTime 被设为当前时间
  markUpdateInLanes(fiber, currentExpirationTime);
}

此时，Child.fiber.expirationTime = currentTimestamp。

阶段 3：自下而上的标记传播

递归继续，beginWork 返回 Child 的 workInProgress，赋值给 workInProgress.child，然后带着这个子节点，回到 Parent。

现在，beginWork 准备处理 Parent。

function beginWork(current, workInProgress, renderExpirationTime) {
  // ... 省略一些初始化代码 ...

  // 核心步骤：检查当前这个 Fiber 是否有需要更新的任务
  checkScheduledUpdateOnFiber(workInProgress, renderExpirationTime);

  // 如果有，或者子节点有更新，我们需要渲染自己
  if (shouldUpdate || workInProgress.expirationTime > renderExpirationTime) {
     // ... 处理更新逻辑 ...
  }
}

在 Parent 的 checkScheduledUpdateOnFiber 执行时，它做了什么？

它看了一眼 Parent.updateQueue。此时，Parent.updateQueue 里可能还没有直接的用户操作，但是，React 的调度器在合并更新时，会把子节点的 expirationTime 拿过来。

注意这个细节： checkScheduledUpdateOnFiber 不仅仅是检查 fiber.expirationTime。如果 fiber.expirationTime 没变，但 fiber.updateQueue 里有东西（比如子节点的更新被合并进来了），React 也会认为这个 Fiber “脏”了。

这就像是：爸爸（Parent）本来没事，但儿子（Child）闯祸了（有更新），爸爸必须跟着一起背锅（渲染）。

所以，Parent 的 expirationTime 被更新为 Child.expirationTime 的值（或者更高优先级的值）。

阶段 4：GrandParent 的觉醒

递归继续，回到 GrandParent。

GrandParent 调用 checkScheduledUpdateOnFiber。它检查自己。它发现 Parent 的 expirationTime 已经变了。这意味着 Parent “脏”了。

如果 GrandParent 有条件渲染，比如：

{someCondition && <Parent />}

那么 GrandParent 必须重新渲染，才能决定要不要渲染 Parent。

如果 GrandParent 是无条件渲染，它也会被标记。因为父组件必须重新计算，才能把新的 Parent（或者带更新状态的 Parent）传给子组件。

四、 代码示例：模拟 checkScheduledUpdateOnFiber 的完整流程

为了让大家彻底明白，我们手写一个简化版的 checkScheduledUpdateOnFiber 和 beginWork 逻辑。

// 假设的 Fiber 节点结构
class FiberNode {
  constructor(tag, props) {
    this.tag = tag;
    this.props = props;
    this.stateNode = null; // 对应的 DOM 节点或组件实例
    this.updateQueue = null; // 更新队列
    this.expirationTime = NoWork; // 过期时间，NoWork 表示没活干
    this.child = null; // 子节点
    this.parent = null; // 父节点引用（用于调试，逻辑上不直接用）
  }
}

// 常量定义
const NoWork = 0;
const Sync = 1; // 同步任务，立即执行
const Input = 2; // 输入相关任务，高优先级

// 核心函数：检查并标记
function checkScheduledUpdateOnFiber(fiber, renderExpirationTime) {
  // 1. 如果 Fiber 自身有更新
  if (fiber.expirationTime !== NoWork && fiber.expirationTime > renderExpirationTime) {
    console.log(`[脏检查] Fiber ${fiber.tag} 自身有更新，时间: ${fiber.expirationTime}`);
    return true;
  }

  // 2. 如果 Fiber 自身没更新，但更新队列里有东西
  // 在 React 源码中，这通常涉及到 lanes 的合并，这里简化处理
  if (fiber.updateQueue && fiber.updateQueue.pending) {
    // 假设更新队列不为空，意味着有子节点的更新被合并进来了
    console.log(`[脏检查] Fiber ${fiber.tag} 更新队列有 pending，标记为脏！`);
    fiber.expirationTime = renderExpirationTime; // 标记自己
    return true;
  }

  return false;
}

// 模拟 beginWork
function beginWork(currentFiber, renderExpirationTime) {
  console.log(`n>>> beginWork 进入 Fiber: ${currentFiber.tag}`);

  // 关键步骤：检查这个节点是否需要更新
  const hasUpdate = checkScheduledUpdateOnFiber(currentFiber, renderExpirationTime);

  if (hasUpdate) {
    console.log(`    -> Fiber ${currentFiber.tag} 决定渲染自己！`);
    // 这里会触发 render，生成新的子节点树
    currentFiber.child = renderComponent(currentFiber); 
  } else {
    console.log(`    -> Fiber ${currentFiber.tag} 没活干，跳过渲染，保持子树不变。`);
  }

  // 递归处理子节点
  if (currentFiber.child) {
    return beginWork(currentFiber.child, renderExpirationTime);
  }

  return null;
}

// 模拟渲染组件
function renderComponent(fiber) {
  // 简单的组件逻辑
  if (fiber.tag === 'Child') {
    const newFiber = new FiberNode('Child', fiber.props);
    // 模拟点击导致状态改变，更新队列不为空
    newFiber.updateQueue = { pending: true }; 
    // 标记为脏
    newFiber.expirationTime = Sync; 
    return newFiber;
  }

  if (fiber.tag === 'Parent') {
    const newFiber = new FiberNode('Parent', fiber.props);
    return newFiber;
  }

  if (fiber.tag === 'GrandParent') {
    const newFiber = new FiberNode('GrandParent', fiber.props);
    return newFiber;
  }
}

// --- 运行测试 ---
console.log("=== React 协调器开始工作 ===");

const rootFiber = new FiberNode('GrandParent', {});
const parentFiber = new FiberNode('Parent', {});
const childFiber = new FiberNode('Child', {});

// 构建树
rootFiber.child = parentFiber;
parentFiber.child = childFiber;

// 模拟时间：现在开始同步渲染
const now = Sync;

// 启动调度
beginWork(rootFiber, now);

运行结果分析：

=== React 协调器开始工作 ===

>>> beginWork 进入 Fiber: GrandParent
    -> Fiber GrandParent 决定渲染自己！
>>> beginWork 进入 Fiber: Parent
    -> Fiber Parent 决定渲染自己！
>>> beginWork 进入 Fiber: Child
    -> Fiber Child 决定渲染自己！
    -> Fiber Child 自身有更新，时间: 1

看到了吗？这就是自下而上的标记路径！

1. Child 最先被处理，发现 Child.expirationTime = 1（有更新）。
2. 回到 Parent，Parent 调用 checkScheduledUpdateOnFiber。虽然 Parent 自己没活，但它看到 Child 有活（通过 updateQueue 或递归返回值），于是 Parent 也被标记为“脏”。
3. 回到 GrandParent，同理，GrandParent 也被标记。

但是！ 如果我们把代码改一下，把 GrandParent 改成一个不依赖子节点的组件呢？

function DummyGrandParent() {
  console.log("DummyGrandParent 渲染了");
  return <div>Only I exist</div>;
}

如果我们把树改成 DummyGrandParent -> Parent -> Child，并且 DummyGrandParent 不引用 Parent 的返回值（或者 Parent 不渲染任何东西），那么当 Child 更新时：

1. Child 变脏。
2. Parent 变脏。
3. DummyGrandParent 不会变脏！

这就是 React 的优化精髓：惰性渲染。checkScheduledUpdateOnFiber 确保了我们只在必要的时候往上冒泡。

五、 为什么是“自下而上”？

很多同学会问：“React 的渲染不是从上往下（Root -> Leaf）的吗？为什么标记更新是自下而上的？”

这涉及到 React 的两个核心阶段：调度和协调。

1. 调度阶段： 用户点击 -> 创建 Update -> 加入队列 -> 标记 Fiber。

   • 这个阶段是自下而上的。用户操作发生在叶子节点（比如一个按钮），状态更新发生在叶子节点，然后这个“意图”被传递给父组件。

2. 协调阶段： 根节点开始遍历 -> beginWork -> completeWork。

   • 这个阶段是自上而下的。根节点决定是否渲染，然后决定渲染子节点。

checkScheduledUpdateOnFiber 就处于这两个阶段的交汇点。

它是在自上而下遍历树的时候，执行自下而上检查的逻辑。

这就好比：

• 你（Root）是老板。
• 你的下属 A（Parent）是经理。
• 下属 A 的下属 B（Child）是实习生。
• 实习生 B 犯了个错（更新了状态）。

调度阶段：实习生 B 告诉经理 A：“我搞砸了。” 经理 A 告诉老板你：“实习生 B 搞砸了，我得处理一下。”（自下而上标记）。

协调阶段：老板你走进办公室，问经理 A：“有活儿吗？” 经理 A 说：“有，实习生 B 搞砸了，我得干活。”（自上而下执行）。

checkScheduledUpdateOnFiber 就是老板问经理 A：“有活儿吗？” 那个瞬间。

六、 深入细节：updateQueue 的魔法

上面为了方便理解，我们简化了 updateQueue。实际上，React 的 updateQueue 是一个双向链表。

class UpdateQueue {
  constructor() {
    this.pending = null; // 待处理的更新队列头
    this.last = null;    // 待处理的更新队列尾
    this.shared = { pending: null }; // 共享状态
  }
}

class Update {
  constructor(action) {
    this.action = action;
    this.next = null; // 下一个更新
  }
}

当 dispatchSetState 被调用时，它会执行 enqueueUpdate：

function enqueueUpdate(fiber, update) {
  const queue = fiber.updateQueue;
  // 如果队列是空的，初始化
  if (queue === null) {
    fiber.updateQueue = new UpdateQueue();
    queue = fiber.updateQueue;
  }

  // 简化版入队逻辑
  if (queue.pending === null) {
    queue.pending = update;
    update.next = update; // 环形链表，自己指自己
  } else {
    const last = queue.pending;
    // 将新更新接到链表末尾
    last.next = update;
    update.next = queue.pending; // 新更新指回头部
    queue.pending = update;      // 更新头部
  }
}

这个环形链表非常重要，因为它允许 React 并发地将多个更新合并成一个。

现在，回到 checkScheduledUpdateOnFiber。

当 beginWork 在 Parent 上运行时，它不仅检查 Parent.expirationTime，它还会检查 Parent.updateQueue.shared.pending。

如果 Parent.updateQueue.shared.pending 不为 null，说明有更新在排队。

React 的逻辑是：如果一个节点有 pending 的更新，它必须被渲染。 这就是为什么即使 Parent 自身没有 setState，只要子节点更新了，Parent 就必须重新渲染。

七、 优先级的博弈：ExpirationTime 的计算

如果只有“脏”和“不脏”，那 React 就不是 React 了。React 有优先级。

checkScheduledUpdateOnFiber 的核心判断逻辑其实是这样的：

function checkScheduledUpdateOnFiber(fiber, renderExpirationTime) {
  const expirationTime = fiber.expirationTime;

  // 如果这个 Fiber 的过期时间 > 当前正在进行的渲染时间
  // 说明这个 Fiber 的更新比当前正在做的任务更紧急
  if (expirationTime !== NoWork && expirationTime > renderExpirationTime) {
    // 1. 标记当前 Fiber 需要被渲染
    // 2. 或者，触发更高优先级的调度
  }
}

这里有个很有趣的现象：越往下的节点，优先级越高。

用户点击 Child，Child 的优先级是最高（比如 Input 优先级）。
Parent 继承了这个优先级。
GrandParent 继承了这个优先级。

如果此时，GrandParent 自己有一个 setTimeout 触发的低优先级更新（比如 DiscreteEvent 之后的 Deferred 任务）。

那么在 beginWork 到达 GrandParent 时：
GrandParent.expirationTime 可能是低优先级（比如 5ms 后）。
renderExpirationTime 可能是高优先级（现在是 0ms）。

expirationTime (5) > renderExpirationTime (0)。条件成立。
GrandParent 被标记为“脏”，并且会打断当前的低优先级任务，优先处理子节点的更新。

这就是 React 的抢占式调度。checkScheduledUpdateOnFiber 就是那个举着旗子喊“Stop!”的裁判。

八、 实战中的坑：为什么有时候子组件更新，父组件没更新？

如果你在开发中遇到过这种情况：子组件 setState 了，但父组件没重新渲染，甚至子组件自己也没重新渲染（数据没变），这通常是因为协调器被中断了，或者没有触发调度。

让我们再看一遍流程：

1. 调度缺失： 如果你的组件没有在 useEffect 或 useLayoutEffect 里调用 dispatchSetState，或者你没有使用 useState，而是用了 useReducer 但没有派发 action，那么 updateQueue 就永远不会被填充。checkScheduledUpdateOnFiber 就永远返回 false。
2. Context 变化： 如果父组件依赖的 Context 值变了，但这不涉及子组件的 updateQueue。子组件需要调用 useContext 并在 render 中读取这个值，React 才会把这个 Context 的更新加入到子组件的 updateQueue 中。
3. Strict Mode： 在 Strict Mode 下，React 会故意挂起并重新挂起组件，这可能会影响 checkScheduledUpdateOnFiber 的执行时机。

九、 总结与展望

好了，同学们，我们今天绕了一大圈，从 checkScheduledUpdateOnFiber 这个函数出发，一路追溯到了 beginWork 的递归调用，又深入到了 updateQueue 的环形链表结构。

我们要记住的核心点只有一个：

checkScheduledUpdateOnFiber 是 React 协调器中“自下而上”标记路径的守门员。

它的工作流程是：

1. 递归进入： beginWork 从 Root 开始往下走。
2. 检查节点： 在每个节点上调用 checkScheduledUpdateOnFiber。
3. 判断脏： 检查节点自身是否有更新，或者更新队列中是否有子节点的更新。
4. 向上传播： 如果脏了，标记当前节点，并递归处理子节点。

这个过程保证了 React 只渲染真正需要更新的部分。它避免了全量 DOM 操作，实现了高效的 Diff 算法的基础。

当然，这只是 React 协调器的一小部分。接下来，我们会看到 completeWork 如何将虚拟 DOM 转换成真实的 DOM 节点，以及 commit 阶段如何把这些变更应用到屏幕上。

但记住，没有 checkScheduledUpdateOnFiber 的精准判断，React 就会变成一个疯狂地在每帧里对所有组件进行 diff 的傻瓜。正是这些看似不起眼的函数，构建了 React 流畅、丝滑的用户体验。

今天的讲座就到这里，下课！记得回去把源码再读三遍，别光听我瞎扯淡！