React 副作用标志位合并：分析 completeWork 阶段如何将子节点的 Flags 合并至父节点

大家好，欢迎来到今天的“React 内部原理深度巡游”。我是你们的向导，今天我们要钻进 React 的肚子里，去看看那个著名的 completeWork 阶段，以及它如何像个不知疲倦的传声筒一样，把子节点身上的“副作用标签”（Flags）一路传到父节点去。

准备好了吗？系好安全带，我们开始吧。

---

第一部分：Fiber 树与“贴标签”的艺术

在 React 的世界里，渲染过程其实就是一场“贴标签”的狂欢。想象一下，你是一个忙碌的工头，面前有一棵巨大的树（Fiber 树）。这棵树不是圣诞树，它是一棵“责任树”。

当 React 开始渲染时，它会从根节点开始，一路向下（beginWork 阶段）。这时候，每个节点都在想：“嘿，我是新的吗？我需要被插入吗？我的属性变了吗？我的子组件变了吗？”

于是，每个节点都会在头顶贴一张便利贴，上面写着它的“副作用标志位”（Flags）。

这些 Flags 其实就是一些二进制位。比如：

• Placement（0x001）：我要被插进 DOM 里了（我是新来的）。
• Update（0x010）：我需要更新一下（我变了）。
• Deletion（0x020）：我要被踢出去了（我失业了）。
• Ref（0x040）：我有一个引用需要更新。

所以，在 beginWork 之后，这棵树的每个节点头上可能都顶着不同的标签。

但是，问题来了。父节点只关心自己的状态，但父节点要怎么知道自己的子树发生了什么变化呢？毕竟，如果子节点变了，父节点渲染了，那父节点在 DOM 上也要动啊。

这就轮到我们的主角 completeWork 登场了。它的任务就是向上走。

---

第二部分：递归的“传声筒”游戏

completeWork 的核心逻辑是一个递归过程。它从叶子节点开始，处理完自己，然后告诉它的父节点：“嘿，我处理完了，顺便告诉你，我底下那些小弟有什么动静。”

这个过程听起来像不像公司里的周报？你写完你的周报，然后向上级汇报，上级再向上级汇报。

在 React 源码中，completeWork 函数的大致逻辑是这样的（为了方便理解，我们简化了类型判断）：

function completeWork(current, workInProgress) {
  const { type } = workInProgress;
  const newProps = workInProgress.memoizedProps;

  // 1. 处理 Fiber 类型（这里是简化版，实际代码有 switch(type)）
  switch (type) {
    case HostComponent: // DOM 元素节点
      // ... 省略具体的 DOM 处理逻辑
      break;
    case HostText: // 文本节点
      // ... 省略文本处理
      break;
    default:
      // 2. 处理函数组件
      // 关键步骤来了！
      // 我们需要把子节点的 Flags 合并到父节点上来
      reconcileChildren(current, workInProgress);
      break;
  }

  // 3. 核心：合并 Flags 逻辑
  // 无论什么类型，最后都要把子节点的信息传上去
  mergeFlags(workInProgress);
  return workInProgress;
}

注意那个 mergeFlags 函数，这就是我们要重点分析的秘密武器。

---

第三部分：Flags 合并的“数学魔法”

在 React 内部，Flags 的合并主要涉及两个变量：

1. flags：当前节点本身的副作用。
2. subtreeFlags：当前节点子树中发现的副作用。

为什么要分开？这就好比：

• flags 是“我自己的事”。
• subtreeFlags 是“我小弟们的事”。

在 completeWork 阶段，父节点必须知道子树的所有情况，因为它要负责把这些副作用打包成一个长长的链表，以便在 commit 阶段执行。

让我们看看这段经典的合并代码：

function mergeFlags(workInProgress) {
  const child = workInProgress.child;

  if (child !== null) {
    // 关键点 1：合并子节点的 subtreeFlags
    // 父节点的 subtreeFlags = 父节点 subtreeFlags | 子节点 subtreeFlags
    workInProgress.subtreeFlags |= child.subtreeFlags;

    // 关键点 2：合并子节点的 flags
    // 父节点的 flags = 父节点 flags | 子节点的 flags
    // 注意：这里是为了收集所有需要被处理的副作用，不仅仅是子树里的
    workInProgress.flags |= child.flags;
  }

  // 递归处理子节点
  if (child) {
    completeWork(null, child);
  }
}

场景分析 1：只有子节点更新了

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

function Parent() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <Child count={count} />
    </div>
  );
}

当 count 变化时：

1. beginWork 遍历到 Child，发现 props.count 变了，于是给 Child 贴上 Update 标签。
2. beginWork 遍历到 Parent，发现 Parent 渲染了（因为子组件变了），所以给 Parent 贴上 Update 标签。
3. 进入 completeWork：
   • 处理 Child：Child.flags = Update，Child.subtreeFlags = 0。
   • 处理 Parent：
     • Parent.flags |= Child.flags -> Parent.flags 变成了 Update | Update（实际上是按位或，依然是 Update）。
     • Parent.subtreeFlags |= Child.subtreeFlags -> Parent.subtreeFlags 保持 0。
4. 结果：Parent 知道自己更新了，Child 知道自己更新了。这没问题。

场景分析 2：子节点被插入（Placement）

这是最经典的场景。父节点没变，但子节点变了。

function Parent() {
  const [show, setShow] = useState(false);
  return (
    <div>
      {show && <Child />}
    </div>
  );
}

当 setShow(true) 时：

1. beginWork 到达 Parent。
2. beginWork 到达 Child。
3. React 发现 Child 是新挂载的（之前不存在），于是给 Child 贴上 Placement 标签。
4. 进入 completeWork：
   • 处理 Child：Child.flags = Placement。
   • 处理 Parent：
     • Parent.flags |= Child.flags -> Parent.flags 变成了 Placement。
     • Parent.subtreeFlags |= Child.flags -> Parent.subtreeFlags 变成了 Placement。
5. 结果：
   • Parent 现在知道自己有一个子节点需要被插入。虽然 Parent 自己的渲染逻辑可能不需要改变（比如它没有状态变化），但为了确保 DOM 的正确性，React 强制让 Parent 也带上 Placement 标签。
   • 为什么？ 因为如果在 commit 阶段，React 遍历 EffectList 时，如果父节点没有 Placement 标签，它可能就不会去处理子节点的插入。这会导致 DOM 树结构错误！

场景分析 3：父节点更新，子节点不更新

如果父节点更新了，子节点没变：

1. Parent 贴上 Update。
2. Child 没有标签。
3. completeWork 合并：
   • Parent.flags |= Child.flags -> 还是 Update。
   • Parent.subtreeFlags |= Child.flags -> 还是 0。
4. 这意味着，虽然父节点更新了，但子树没有副作用。React 只会更新父节点，完全跳过子节点的 completeWork 逻辑，节省性能。

---

第四部分：深入 subtreeFlags 与 flags 的区别

这是很多初学者容易晕的地方。我们再来理一理这两个兄弟的区别。

flags：代表当前节点本身需要执行的操作。
subtreeFlags：代表当前节点及其所有后代中需要执行的操作。

在 completeWork 中，父节点的 flags 会包含子节点的 flags，但父节点的 subtreeFlags 会包含子节点的 subtreeFlags。

这意味着什么？
这意味着，如果你在 beginWork 中给一个子节点贴了标签，这个标签会穿透所有父节点，直到根节点。

看这个例子：

function GrandParent() {
  return <Parent><Child /></Parent>;
}

如果 Child 变了：

1. Child.flags = Update。
2. Parent.flags |= Child.flags -> Parent.flags = Update。
3. Parent.subtreeFlags |= Child.flags -> Parent.subtreeFlags = Update。
4. GrandParent.flags |= Parent.flags -> GrandParent.flags = Update。
5. GrandParent.subtreeFlags |= Parent.subtreeFlags -> GrandParent.subtreeFlags = Update。

最终，从 GrandParent 到 Child，所有节点都标记了 Update。这在 React 的 commit 阶段非常重要，因为 React 需要按照这个标记顺序来处理副作用，确保先处理父节点的副作用，再处理子节点的副作用（或者反过来，取决于具体的 EffectList 顺序，但必须保证层级关系）。

---

第五部分：构建 EffectList（副作用链表）

Flags 合并的最终目的是为了构建那个著名的 EffectList（副作用链表）。这个链表是单向的，每个节点都有一个 nextEffect 指针。

completeWork 不仅合并 Flags，还负责构建这个链表。

function completeWork(current, workInProgress) {
  // ... 之前的逻辑

  // 处理 Flags 并构建 EffectList
  if ((flags & Placement) !== NoFlags) {
    // 如果当前节点有 Placement 标志
    const currentFirstChild = current !== null ? current.firstEffect : null;
    const nextFirstEffect = workInProgress.firstEffect;

    // 将当前节点的 EffectList 接到父节点的 EffectList 后面
    // 这是一个链表拼接操作
    workInProgress.firstEffect = currentFirstChild;
    workInProgress.nextEffect = nextFirstEffect;

    if (nextFirstEffect) {
      nextFirstEffect.previousEffect = workInProgress;
    }
    if (currentFirstChild) {
      currentFirstChild.previousEffect = workInProgress;
    }
  }

  // 递归
  if (child) {
    completeWork(null, child);
  }
}

链表拼接的奥秘

想象一下，completeWork 是从下往上遍历的。当它处理完 Child 时，Child 已经有了自己的 firstEffect。当它处理完 Parent 时，它需要把 Child 的 EffectList 挂在 Parent 的后面。

这就像穿珠子。

1. 处理 Child：Child 挂上珠子 A。
2. 处理 Parent：Parent 挂上 Child 的珠子 A。
3. 处理 GrandParent：GrandParent 挂上 Parent 的珠子 A。

最终，根节点（HostRoot）会拥有一个完整的、从上到下（或从下到上）的 EffectList。

这个链表在 commit 阶段会被遍历。React 根据链表顺序执行副作用：

1. Layout Effects：在 DOM 更新之后执行。
2. DOM Updates：根据 Placement/Update 标签更新 DOM。
3. Passive Effects（useEffect）：在 DOM 更新之后，下一帧执行。

---

第六部分：特殊情况与边界条件

代码从来都不是完美的，React 的 completeWork 也有它的“奇葩”时刻。

1. 删除节点

当节点被删除时，情况会变得有点复杂。
如果一个节点被删除，它的 flags 会包含 Deletion。
在 completeWork 中，Deletion 的处理逻辑和 Placement 或 Update 不同。Deletion 通常是反向处理的（从后往前删除，防止索引错乱）。

当 completeWork 向上合并时，如果子节点有 Deletion，父节点也会继承这个标志。但父节点通常不会在 DOM 中执行删除操作（因为父节点还在），而是把这个责任交给它的父节点，或者通过某种机制标记需要清理。

2. 文本节点

文本节点比较特殊。React 不给文本节点分配独立的 EffectList（除非它被插入或删除）。
如果文本节点的内容变了，React 会在父节点的 flags 中标记 Update（因为父节点要重新渲染这个文本节点），但文本节点本身可能没有 Placement 标志。

3. Fragment 与 Portal

• Fragment：通常不产生副作用，因为它不渲染成真实的 DOM 节点。所以 completeWork 处理 Fragment 时，会把子节点的 Flags “透传”过去，但 Fragment 自己不挂载任何副作用。
• Portal：Portal 渲染到 DOM 树的其他位置。completeWork 会把 Portal 的副作用（比如 ref 更新）合并到父节点，但 Portal 的 DOM 操作逻辑是独立的。

---

第七部分：代码实战演练

让我们来写一段稍微复杂一点的代码，模拟 completeWork 的合并过程。为了直观，我们手写一个微型 React 的 completeWork 逻辑。

// 定义 Flags 常量
const NoFlags = 0b0000;
const Placement = 0b0001;
const Update = 0b0010;
const Deletion = 0b0100;

interface FiberNode {
  type: any;
  flags: number;
  subtreeFlags: number;
  child: FiberNode | null;
  firstEffect: FiberNode | null; // 用于构建 EffectList
  nextEffect: FiberNode | null;
  previousEffect: FiberNode | null;
}

// 模拟一个简单的 completeWork 函数
function completeWork(node: FiberNode) {
  console.log(`Processing node: ${node.type}`);

  // 1. 如果有子节点，先递归处理子节点
  // 注意：这是深度优先遍历
  if (node.child) {
    completeWork(node.child);
  }

  // 2. 合并子节点的 Flags
  // 这是核心逻辑
  if (node.child) {
    // 合并子树副作用
    node.subtreeFlags |= node.child.subtreeFlags;

    // 合并自身副作用
    node.flags |= node.child.flags;

    console.log(`  Merging child flags into parent. 
      Child Flags: ${node.child.flags}, 
      Parent Flags: ${node.flags}`);
  }

  // 3. 构建 EffectList (简化版)
  // 如果当前节点有副作用，把它挂到父节点的链表上
  if (node.flags !== NoFlags && node.parent) {
    // 这里省略了具体的链表指针操作，逻辑是：
    // current.nextEffect = node;
    // node.previousEffect = current;
    console.log(`  -> EffectList updated. Node ${node.type} added to effect list.`);
  }
}

// --- 模拟场景 ---

// 构建一棵树
const root: FiberNode = {
  type: 'HostRoot',
  flags: NoFlags,
  subtreeFlags: NoFlags,
  child: null,
  firstEffect: null,
  nextEffect: null,
};

const parent: FiberNode = {
  type: 'Parent',
  flags: NoFlags, // 父节点本身没变，但会继承子节点的
  subtreeFlags: NoFlags,
  child: null,
  nextEffect: null,
};

const child: FiberNode = {
  type: 'Child',
  flags: Placement, // 子节点被插入了！
  subtreeFlags: NoFlags,
  child: null,
  nextEffect: null,
};

// 连接树
parent.child = child;
root.child = parent;

// 执行 completeWork
console.log("--- Start completeWork ---");
completeWork(root);
console.log("--- End completeWork ---");

// --- 预期输出分析 ---
/*
Processing node: Child
Processing node: Parent
  Merging child flags into parent. 
    Child Flags: 1, 
    Parent Flags: 1
  -> EffectList updated. Node Child added to effect list.
Processing node: HostRoot
  Merging child flags into parent. 
    Child Flags: 1, 
    Parent Flags: 1
  -> EffectList updated. Node HostRoot added to effect list.
  Merging child flags into parent. 
    Child Flags: 1, 
    Parent Flags: 1
  -> EffectList updated. Node Parent added to effect list.
*/

看，这个过程是不是很清晰？子节点 Child 带着 Placement 标签往上走，一路经过 Parent 和 HostRoot，给它们都打上了标记，并把它们加入到了 EffectList 中。

---

第八部分：为什么我们需要这样做？（性能与正确性的平衡）

你可能会问：“既然子节点变了，React 只需要更新子节点不就行了吗？为什么要把父节点也标记为 Update？”

这涉及到 React 的批量更新和DOM 层级的问题。

1. 层级一致性：React 认为 DOM 是树形的。如果子节点插入了，父节点在 DOM 树中的位置也发生了变化（即使父节点本身没有渲染逻辑上的变化）。为了保持逻辑的一致性，父节点必须被渲染，并且被标记为有副作用。
2. EffectList 的完整性：commit 阶段需要按照层级顺序执行副作用。如果父节点没有标记，它就不会出现在 EffectList 中，那么它的子节点的副作用可能就不会被执行，或者执行的时机不对。
3. 复用：虽然父节点标记了 Update，但如果父节点没有状态变化（没有 memoizedState 的变化），React 在 beginWork 阶段可能会进行优化，比如复用旧的 Fiber 节点，而不是创建全新的节点。这种标记只是“通知”，并不一定意味着“重建”。

第九部分：总结与展望

completeWork 阶段就像是 React 渲染流程中的“收尾工作”。

• 向下看：beginWork 负责创造和分配任务（Flags）。
• 向上看：completeWork 负责收集任务，合并子节点的副作用到父节点，并构建最终的 EffectList。

通过位运算（|=）和递归，React 确保了无论 DOM 树变得多么复杂，无论副作用发生在哪个角落，最终都能被准确地收集起来，并在 commit 阶段有序地执行。

理解了 completeWork，你就理解了 React 为什么能如此高效地管理 DOM 变化。它不是盲目地更新每一个字符，而是像一位精明的指挥官，指挥着每一个 Fiber 节点，确保每一处变动都恰到好处，不多不少。

下次当你看到 React 在控制台里疯狂地打印日志，或者当你看到页面上的列表更新时，希望你能想到这棵树，以及那些在 completeWork 阶段默默合并 Flags 的节点们。它们是 React 世界的无名英雄。

好了，今天的讲座就到这里。希望大家回去之后，看到自己的组件树，能像看到自己家谱系一样清晰。如果有任何问题，欢迎在评论区扔砖头！我们下期再见！