React beginWork 阶段组件分发机制：乐高积木的奇幻漂流

大家好，欢迎来到今天的“React 内部架构深度游”讲座。

今天我们要聊的，是 React 渲染管线中那个最忙碌、最早醒来的“打工人”——beginWork。

如果你觉得 React 的 Fiber 架构像天书，没关系，今天我们不谈玄学，只谈“物流”。想象一下，React 就是一个巨大的乐高积木工厂。每当用户点击了一个按钮，或者父组件传进来了新的 props，工厂就得重新盘点库存。beginWork 就是那个第一个冲进仓库，开始核对订单和现有积木匹配度的工头。

他的任务只有一个：分发任务。

把任务分发给谁？分发给 DOM 节点、分发给文本节点、还是分发给那些复杂的函数组件？这就是我们今天要深扒的——组件分发机制。

准备好了吗？深吸一口气，我们要钻进 React 的肚子里了。

---

第一章：Fiber 架构下的“早高峰”

在 React 15 时代，我们的渲染是同步的、递归的。就像一个程序员在写代码时，突然发现逻辑跑偏了，整个线程就被卡死，页面直接白屏。

到了 React 16，Fiber 架构横空出世。它把渲染任务拆碎成了一个个小的“工作单元”。beginWork 就是这些工作单元的入口函数。

它的核心签名大概是这样的（源码简化版）：

function beginWork(
  current: Fiber | null,      // 上一帧渲染好的那个 Fiber 节点（老版本）
  workInProgress: Fiber,     // 当前正在构建的新 Fiber 节点（新版本）
  renderLanes: Lanes          // 当前任务的优先级
): Fiber | null {
  // 核心逻辑就在下面
  const tag = workInProgress.tag;

  switch (tag) {
    case HostComponent:
      return updateHostComponent(current, workInProgress, renderLanes);
    case HostText:
      return updateHostText(current, workInProgress, renderLanes);
    case FunctionComponent:
      return updateFunctionComponent(current, workInProgress, renderLanes);
    case ClassComponent:
      return updateClassComponent(current, workInProgress, renderLanes);
    // ... 还有很多其他 tag
    default:
      return null;
  }
}

看到了吗？这个 switch (tag) 就是分发机制的起点。

React 把不同的组件类型分发给不同的处理函数。HostComponent（比如 <div>）去找 updateHostComponent，FunctionComponent（比如 <Button />）去找 updateFunctionComponent。

这就像是一家餐厅，后厨有三个厨师：

1. 切配师傅（HostComponent）：专门处理肉和菜（DOM 节点）。
2. 掌勺师傅（FunctionComponent）：专门处理复杂的菜谱（函数组件逻辑）。
3. 传菜员（HostText）：专门端盘子上的汤水（文本节点）。

beginWork 的第一件事，就是看这道菜属于谁，然后把它扔给对应的师傅。

---

第二章：核心战场——reconcileChildren

分发只是第一步，真正的重头戏在于如何处理子节点。这就是 reconcileChildren 函数的舞台。

React 的哲学是：尽量复用。如果父组件传来的子节点和上一次渲染的一模一样，那就别动它，睡大觉去；如果不一样，那就把它“复活”或者“销毁”。

这里的逻辑非常精妙，它主要分为两种模式：

1. 挂载模式：current 是 null。这是第一次渲染，或者组件刚从内存里被“复活”。这时候没有旧节点可复用，只能新建。
2. 更新模式：current 存在。这是组件已经渲染过一次了，我们要对比新旧数据。

我们来看 reconcileChildren 的核心逻辑（伪代码版）：

function reconcileChildren(
  current: Fiber | null,
  workInProgress: Fiber,
  nextChildren: Array<any> | object,
  renderLanes: Lanes
) {
  // 1. 如果是挂载模式，或者没有 current 节点
  if (current === null) {
    // 挂载模式：不管三七二十一，把 nextChildren 全部创建成新的 Fiber 节点
    workInProgress.child = mountChildFibers(workInProgress, null, nextChildren, renderLanes);
  } else {
    // 2. 如果是更新模式，这就开始了“灵魂拷问”
    // React 想知道：nextChildren 和 current.child 有什么关系？

    // 简化版逻辑：如果 key 一样，复用；不一样，丢弃重造。
    // 这里实际上会调用 ChildReconciler 或 MountChildReconciler
    workInProgress.child = reconcileChildFibers(
      workInProgress, 
      current.child, 
      nextChildren, 
      renderLanes
    );
  }
}

这里的 reconcileChildFibers 就是分发机制的大脑。它负责遍历 nextChildren（React 的虚拟 DOM 数组），然后一个个地去 current 的子节点树里找匹配项。

---

第三章：ChildReconciler 的“生离死别”

这里要隆重介绍一个核心工具函数：reconcileChildFibers。它的内部实现非常长，但我们可以把它想象成一个“配对师”。

配对师手里拿着一叠新的卡片（nextChildren），然后去旧的一叠卡片堆里找。

3.1 单子树与多子树

React 为了优化性能，把子节点分为“单子树”和“多子树”。

• 单子树：通常指 Fragment 或者只包含一个元素的数组。配对师处理起来很简单：直接比对 key，一样就复用，不一样就销毁重建。
• 多子树：比如 <ul><li>A</li><li>B</li></ul>。这就要复杂多了，因为 React 需要处理列表的增删改查。

3.2 Key：灵魂的标签

在分发过程中，key 属性起到了决定性作用。

假设我们有一个列表：

// 旧列表
<Li key="a" /> <Li key="b" />

// 新列表
<Li key="b" /> <Li key="a" /> // 顺序变了

当 beginWork 遍历到第一个子节点 key="b" 时，它会在旧树里找 key="b"。

• 找到了！ 好，那这个 Li 组件的 Fiber 节点直接拿来用，复用！
• 没找到！ 那只能新建一个 Fiber 节点，挂载上去。

代码示例：Key 的作用

// 假设这是 beginWork 的一个简化循环
function reconcileChildrenIterator(workInProgress, nextChildren) {
  let resultingFirstChild = null;
  let previousNewFiber = null;
  let newChildren = nextChildren;

  // 假设我们拿到了新的子节点数组
  // [ { type: 'li', key: 'b' }, { type: 'li', key: 'a' } ]

  for (let i = 0; i < newChildren.length; i++) {
    let child = newChildren[i];

    // --- 核心分发逻辑 ---

    // 1. 根据 type 和 key 创建一个新的临时 Fiber 节点
    let newFiber = createFiberFromNode(child);

    // 2. 尝试去 current 树里找匹配的旧 Fiber
    // 这里就是“分发”的核心：找不找得到？
    let matchedFiber = findMatchingFiber(currentChild, newFiber.key, newFiber.type);

    if (matchedFiber) {
      // 如果找到了（复用）
      // 更新 props，标记状态为更新
      newFiber = updateFiber(matchedFiber, newFiber); 
    } else {
      // 如果没找到（新建）
      newFiber.effectTag = Placement; // 标记为插入
    }

    // 3. 把新节点挂到链表上
    if (resultingFirstChild === null) {
      resultingFirstChild = newFiber;
    } else {
      previousNewFiber.sibling = newFiber;
    }
    previousNewFiber = newFiber;
  }

  return resultingFirstChild;
}

这个 findMatchingFiber 就是分发机制的“上帝之手”。如果没有 key，React 只能通过索引来比对。如果列表顺序变了，React 就会傻眼：索引0原来对应的是 A，现在变成了 B，它就会把 B 当成 A 来处理，导致 DOM 节点错乱。

所以，分发机制的第一条铁律：Key 是定位符，不是装饰品。

---

第四章：不同组件类型的分发策略

好了，我们已经知道了如何分发“子节点”。现在，让我们回到 beginWork 的入口，看看当它拿到一个组件节点时，具体怎么分发。

4.1 HostComponent：DOM 节点的搬运工

当 tag 是 HostComponent 时，比如 <div>，beginWork 会调用 updateHostComponent。

这个函数主要做两件事：

1. Diff Props：对比 pendingProps 和 memoizedProps。如果 className 变了，style 变了，它会在 completeWork 阶段生成 MutationMask，标记这些属性需要更新。
2. 创建子节点：它调用 reconcileChildren 来处理 div 里面的 <span> 或者 <p>。

// updateHostComponent 的简化逻辑
function updateHostComponent(current, workInProgress, renderLanes) {
  const type = workInProgress.type;
  const nextProps = workInProgress.pendingProps;

  // 1. 复用旧的 props，更新新的 props
  const updatePayload = workInProgress.updateQueue;
  if (updatePayload) {
    workInProgress.memoizedProps = nextProps;
  }

  // 2. 分发子任务
  // 注意：这里必须调用 reconcileChildren，否则 div 里面的东西就没了
  reconcileChildren(
    current, 
    workInProgress, 
    nextProps.children, 
    renderLanes
  );

  // 3. 返回第一个子节点，继续递归
  return workInProgress.child;
}

4.2 FunctionComponent：函数组件的“黑魔法”

这是 React 13/14/15/16 的分水岭。

当 tag 是 FunctionComponent 时，beginWork 会调用 updateFunctionComponent。

关键点来了： beginWork 阶段，FunctionComponent 其实并不执行组件本身的代码！

它只是调度执行。它把当前的任务（renderLanes）传递给组件，然后等待组件返回子节点。

function updateFunctionComponent(current, workInProgress, renderLanes) {
  const nextProps = workInProgress.pendingProps;
  const type = workInProgress.type;

  // 1. 准备 Hooks 环境
  prepareToUseHooks(workInProgress, renderLanes);

  // 2. 调用组件函数
  // 这一步非常关键，它把任务“分发”给了用户的代码
  const children = type(nextProps, context);

  // 3. 检查 Hooks 是否被滥用
  checkDidRenderHookSideEffects();

  // 4. 再次分发！
  // 组件返回的 children（可能是数组，也可能是单个对象），
  // 需要被重新塞回 reconcileChildren 流程中。
  reconcileChildren(
    current, 
    workInProgress, 
    children, 
    renderLanes
  );

  return workInProgress.child;
}

这里有一个非常有趣的递归：

1. beginWork 拿到 <App />（FunctionComponent）。
2. beginWork 发现是 FunctionComponent。
3. beginWork 调用 <App />，拿到它的返回值 <Header />。
4. beginWork 拿到 <Header />，发现是 FunctionComponent。
5. beginWork 调用 <Header />，拿到它的返回值 <h1>Hello</h1>。
6. beginWork 拿到 <h1>，发现是 HostComponent。
7. beginWork 调用 updateHostComponent，处理 <h1>。

这就是 React 的深度优先遍历。它像一条贪吃蛇，一条路走到黑，先处理完所有子节点，再回溯。

4.3 ClassComponent：老派绅士

对于 ClassComponent，beginWork 会调用 updateClassComponent。

它的逻辑稍微复杂一点，因为涉及到 state 和 props 的更新队列。

function updateClassComponent(current, workInProgress, renderLanes) {
  // 1. 处理状态更新队列
  // 把 pendingStateQueue 里的值合并到 state 里
  processUpdateQueue(workInProgress);

  // 2. 准备上下文
  const nextProps = workInProgress.pendingProps;
  const instance = workInProgress.stateNode;

  // 3. 调用 render 方法
  // 注意：这里调用的是 this.render()，不是 React.render()
  const nextChildren = instance.render();

  // 4. 分发
  reconcileChildren(current, workInProgress, nextChildren, renderLanes);

  return workInProgress.child;
}

4.4 HostText：最简单的节点

文本节点是所有节点里最“憨”的。

当 tag 是 HostText 时，beginWork 调用 updateHostText。

它的逻辑非常简单粗暴：只比较内容。

function updateHostText(current, workInProgress, renderLanes) {
  // 如果当前节点存在
  if (current !== null) {
    const oldText = current.memoizedProps;
    const newText = workInProgress.pendingProps;

    // 如果内容变了
    if (oldText !== newText) {
      // 标记为更新文本内容
      workInProgress.effectTag |= Update;
    }
  }

  // 无论变没变，都要递归处理子节点（文本节点通常没有子节点，或者子节点是 undefined）
  return null; // HostText 没有 child
}

---

第五章：memo 和 useMemo 的“作弊”机制

讲到这儿，大家可能觉得 beginWork 的分发机制有点“傻”。它不管三七二十一，只要 key 不一样，就销毁重建。那 React.memo 和 useMemo 岂不是没用？

大错特错！ 这正是 beginWork 机制的精妙之处。

memo 和 useMemo 的作用，是在 beginWork 之前，拦截一下请求。

5.1 React.memo 的拦截

当你写 <MemoComponent /> 时，React 会把这个组件包装一下。

在 beginWork 进入这个组件之前，React 会先问一个问题：我的 props 变了吗？

如果 props 没变，React 会直接告诉 beginWork：“别进去了，别执行那个函数了，直接复用上一次的 Fiber 节点就行了。”

这就像你点外卖，如果你上次点的菜还没吃完，外卖员（beginWork）直接就把剩下的端上来了，根本不用再去厨房点菜。

代码示例：memo 的工作原理

// React 内部可能会这样处理 memo 组件
function renderWithHooks(...) {
  // ... 省略准备 hooks 的代码

  // 假设我们有一个 memo 包装器
  const Component = workInProgress.type;

  // 1. 检查 memo
  if (Component.isReactMemoComponent) {
    // 这里的逻辑是：对比 current.memoizedProps 和 workInProgress.pendingProps
    if (workInProgress.memoizedProps === workInProgress.pendingProps) {
      // 如果 props 没变，直接复用
      // 不调用 render 函数，不执行 beginWork 的后续逻辑
      return current;
    }
  }

  // 2. 如果 props 变了，或者不是 memo，那就老老实实走流程
  const children = Component(props, context);
  return reconcileChildren(current, workInProgress, children, renderLanes);
}

5.2 useMemo 的延迟分发

useMemo 也是一样的道理。它告诉 beginWork：“别现在计算结果，先算完别的，等会儿再算。”

如果 useMemo 的依赖项没变，beginWork 就会跳过计算，直接把缓存的值拿出来。

---

第六章：Lanes（优先级）与“跳过”机制

前面我们一直在说“分发”，但没说“跳过”。在 React 18 的并发模式下，beginWork 的分发机制变得更加智能。

假设你有一个巨大的列表（1000 个 <li>），用户正在疯狂滚动页面，这时候系统后台正在执行一个高优先级的动画任务。

React 的 beginWork 每次拿到一个节点，都会先检查 renderLanes（渲染优先级）。

function beginWork(current, workInProgress, renderLanes) {
  // 1. 检查这个节点是否在当前优先级队列中
  if (!includesSomeLane(renderLanes, workInProgress.lanes)) {
    // 如果这个节点的优先级太低（比如它对应的 DOM 在屏幕外，或者它的更新是低优先级的）
    // beginWork 会直接返回 null。
    return null;
  }

  // 2. 如果优先级足够高，才继续分发和执行
  const tag = workInProgress.tag;
  // ... switch 逻辑
}

这就是时间切片的基石。beginWork 就像一个精明的调度员，它不是把所有任务都塞给 CPU，而是挑着最紧急的任务做。不紧急的任务，它直接扔一边（返回 null），等到下一次调度再处理。

---

第七章：完整的代码演练

为了让大家彻底明白，我们来模拟一个完整的 beginWork 调用链。

假设我们有这样一个组件树：

function App() {
  return (
    <div className="container">
      <Header title="Hello" />
      <Content>
        <p>First paragraph</p>
        <p>Second paragraph</p>
      </Content>
    </div>
  );
}

React 构建的 Fiber 结构大概是这样（简化）：

// 根节点 Fiber
rootFiber = {
  tag: HostRoot,
  child: AppFiber,
  stateNode: fiberRootNode
};

// App Fiber
AppFiber = {
  tag: FunctionComponent,
  stateNode: App,
  child: ContainerDivFiber,
  memoizedProps: { ... }
};

// ContainerDiv Fiber
ContainerDivFiber = {
  tag: HostComponent,
  stateNode: div,
  child: HeaderFiber,
  memoizedProps: { className: "container" }
};

// Header Fiber
HeaderFiber = {
  tag: FunctionComponent,
  stateNode: Header,
  child: null // 或者是文本节点
};

当 beginWork 从根节点开始执行时：

1. 执行 beginWork(rootFiber)：

   • tag 是 HostRoot。
   • 调用 updateHostRoot。
   • updateHostRoot 调用 reconcileChildren。
   • reconcileChildren 发现 AppFiber 是 current 的 child，且类型匹配。
   • 返回 AppFiber。

2. 执行 beginWork(AppFiber)：

   • tag 是 FunctionComponent。
   • 调用 updateFunctionComponent。
   • 调用 App(props)。
   • App 返回了虚拟 DOM：<div className="container">...</div>。
   • updateFunctionComponent 调用 reconcileChildren。
   • reconcileChildren 把返回的 div 对应的 Fiber 节点（ContainerDivFiber）挂载到 AppFiber.child。
   • 返回 ContainerDivFiber。

3. 执行 beginWork(ContainerDivFiber)：

   • tag 是 HostComponent。
   • 调用 updateHostComponent。
   • 对比 className，没变。
   • 调用 reconcileChildren 处理子节点。
   • 返回 HeaderFiber。

4. 执行 beginWork(HeaderFiber)：

   • tag 是 FunctionComponent。
   • 调用 updateFunctionComponent。
   • 调用 Header(props)。
   • Header 返回 <h1>Hello</h1>。
   • 返回 H1Fiber。

5. 执行 beginWork(H1Fiber)：

   • tag 是 HostComponent。
   • 调用 updateHostComponent。
   • 返回 null（因为 H1 没有子节点了）。

6. 回溯：

   • beginWork 收到 null，它知道子节点处理完了。
   • 它开始处理兄弟节点（如果有）。
   • 如果没有兄弟节点，它返回 null 给父节点。
   • 父节点处理完兄弟节点，也返回 null。
   • 最终回到根节点，beginWork 结束，进入 completeWork 阶段。

---

第八章：总结与吐槽

好了，老铁们，今天的讲座接近尾声。

我们回顾一下 beginWork 的组件分发机制：

1. 识别身份：通过 tag 判断是 DOM 节点、函数组件还是类组件。
2. 分发任务：根据身份调用不同的处理函数（updateHostComponent, updateFunctionComponent 等）。
3. 处理子节点：核心是 reconcileChildren，通过 Key 和 Type 进行节点复用或新建。
4. 优先级控制：利用 Lanes 机制，决定什么时候做，什么时候跳过。

我觉得 React 的这个机制最酷的地方在于它的“责任链”。
beginWork 不负责具体渲染 DOM，也不负责计算状态，它只负责把“这是谁、有什么子节点、优先级多少”这些信息分发下去。这种职责分离，让 React 能够极其灵活地处理各种边缘情况。

当然，这个机制也有“副作用”。因为它是深度优先的，如果你在一个递归很深的组件里写了死循环，React 的 beginWork 就会像推石头的西西弗斯一样，永远停不下来，直到内存爆炸。

所以，写代码的时候，记得给你的函数组件加 key，记得控制好递归深度，别让我们的 beginWork 工头累死在工地上。

下课！

(注：本文基于 React 18 源码逻辑进行解析，部分代码为便于理解进行了伪代码简化，实际源码逻辑更加繁复和严谨。)