React completeWork 阶段副作用冒泡原理

各位同学，大家好！

欢迎来到今天的“React 源码深度巡游”现场。我是你们的老朋友，那个喜欢在代码堆里找乐子，试图把 React 这种“魔法”变成“科学”的讲师。

今天，我们要聊一个听起来很高大上，实际上却是 React 性能优化和渲染机制基石的话题——React completeWork 阶段副作用冒泡原理。

听到“副作用”和“冒泡”这两个词，大家脑子里是不是瞬间浮现出了 DOM 事件监听、useEffect 的执行，或者类似事件冒泡的机制？别急，今天我们不谈那些花里胡哨的 UI 动画，我们要钻进 React 的肚子里，去看看它是怎么“干活”的。

准备好了吗？咱们把手里的咖啡放一放，把键盘敲响，今天我们要深入 React 的“收尾阶段”。

第一部分：Fiber 树的“装修队”分工

在进入 completeWork 之前，咱们得先搞清楚 React 的渲染过程到底经历了什么。很多人以为 React 就是把组件渲染成 DOM，然后啪的一下插进页面。错！大错特错！

React 的渲染过程，本质上是一场精心编排的“装修工程”。

想象一下，我们要把一套房子装修好。装修队里有几个工种：

1. 设计师（BeginWork）：负责看图纸，拆旧墙，规划新结构，确定哪里要放沙发，哪里要放冰箱。它主要在“向下”走，处理子节点。
2. 施工队（CompleteWork）：负责把设计师规划的图纸变成实物。它负责把砖头砌好，把油漆刷上，最后把所有东西汇总，交给监理（Commit阶段）去验收。

beginWork 的主要任务是什么？是创建。它负责遍历 Fiber 树，根据 newProps 和 oldFiber，决定是复用旧节点，还是创建新节点。它就像一个忙碌的工头，不断地往下钻，建立父子关系。

而到了 completeWork 阶段，画风突变。工头不再往下钻了，他开始向上收尾。他的任务是把当前这个节点处理完，然后去处理它的兄弟节点，最后处理它的父亲。

这就引出了我们今天的主角——副作用冒泡。

第二部分：什么是“副作用冒泡”？

在 React 的世界里，每个 Fiber 节点都有一个 flags 属性（或者叫 subtreeFlags）。这个属性就像是贴在这个节点上的“工单”，写着：“嘿，我这边有点事儿没干完，比如我要挂载 DOM 了”、“我要更新 DOM 了”、“我要触发 useEffect 了”。

completeWork 的核心逻辑，就是处理这些“工单”。

所谓的副作用冒泡，其实并不是一种像 DOM 事件那样的层层传递，而是一种遍历顺序。

React 的 completeWork 函数，在遍历树的时候，遵循的是一种特殊的路径：先左子，后右子，再兄弟，最后父节点。

这听起来是不是有点耳熟？这简直就是树的“后序遍历”（Post-order Traversal）。

为什么是后序遍历？因为父节点的“副作用”往往依赖于子节点。

举个例子：
你有一个父组件 Parent，里面有个子组件 Child。
父组件想对子组件的 DOM 节点做一个操作（比如通过 ref 获取子组件的尺寸），或者父组件的 useEffect 需要在子组件渲染完毕后执行。

如果 React 先处理父节点，再处理子节点，那子组件还没长出来呢，父组件怎么操作子组件？这就尴尬了。

所以，React 的 completeWork 必须得像个负责任的家长：先让孩子（子节点）把作业写完，把身体长好（DOM 挂载好），然后家长（父节点）才能开始处理自己的事务。

这就叫副作用冒泡——子节点的副作用先处理，父节点的副作用后处理。

第三部分：代码里的“冒泡”逻辑

为了让大家看清楚，咱们不直接上几万行的 React 源码（那样会睡着），咱们手写一个简化版的 completeWork 逻辑，模拟这个过程。

假设我们有一个简单的 Fiber 结构：

// 模拟 Fiber 节点
interface FiberNode {
  return: FiberNode | null; // 父节点
  child: FiberNode | null;  // 第一个子节点
  sibling: FiberNode | null; // 下一个兄弟节点
  flags: Flags;             // 标志位
  stateNode: any;           // 实际的 DOM 节点（如果是 HostComponent）
  type: string;             // 组件类型
  nextEffect: FiberNode | null; // 下一个需要处理的副作用节点
}

// 模拟标志位
enum Flags {
  Placement = 0x0001, // 插入
  Update = 0x0002,    // 更新
  Deletion = 0x0004,  // 删除
  Ref = 0x0010,       // Ref 回调
}

// 模拟 completeWork 的核心循环
function completeWork(current: FiberNode | null, workInProgress: FiberNode): FiberNode {
  // 1. 获取当前节点的类型
  const newType = workInProgress.type;

  // 2. 根据类型分发处理逻辑
  // 这里我们主要关注 HostComponent（DOM节点）和 FunctionComponent（组件）
  if (newType === 'div') {
    // 处理 DOM 节点
    completeHostComponent(workInProgress);
  } else if (newType === 'ChildComponent') {
    // 处理子组件
    completeChildComponent(workInProgress);
  }

  // 3. 核心：副作用冒泡逻辑
  // 如果当前节点有副作用，我们需要把它加到父节点的 effectList 里
  // 这一步体现了“冒泡”的概念：把当前节点的副作用交给它的父节点去管理

  if (workInProgress.flags !== NoFlags) {
    // 将当前节点挂载到父节点的 nextEffect 链表上
    // 注意：这里只是逻辑上的挂载，真正的 DOM 更新在 commit 阶段
    if (workInProgress.return) {
      const parent = workInProgress.return;

      // 如果父节点还没有 nextEffect，那就挂上去
      if (!parent.nextEffect) {
        parent.nextEffect = workInProgress;
      } else {
        // 否则，找到父节点的 effectList 尾巴，挂上去
        let lastEffect = parent.nextEffect;
        while (lastEffect.nextEffect) {
          lastEffect = lastEffect.nextEffect;
        }
        lastEffect.nextEffect = workInProgress;
      }
    }
  }

  // 4. 返回下一个要处理的节点
  // 逻辑：先处理完 child，再处理完 child 的兄弟，最后回到父节点
  // 所以下一个节点默认是 sibling，如果没有 sibling，就是 return
  if (workInProgress.sibling) {
    return workInProgress.sibling;
  } else {
    return workInProgress.return;
  }
}

// 模拟处理 DOM 节点的具体动作
function completeHostComponent(workInProgress: FiberNode) {
  // 1. 如果是挂载，创建 DOM
  if (!workInProgress.stateNode) {
    // 这里的逻辑非常简化，实际 React 会创建真实的 DOM 节点
    const instance = document.createElement('div');
    instance.textContent = workInProgress.pendingProps.children;
    workInProgress.stateNode = instance;
  } 
  // 2. 如果是更新，修改 DOM
  else {
    const instance = workInProgress.stateNode;
    // 更新文本内容或属性...
  }

  // 3. 处理 Ref
  // Ref 的处理非常特殊，它必须等到 DOM 创建完成后才能赋值
  if (workInProgress.flags & Flags.Ref) {
    const ref = workInProgress.ref;
    if (ref) {
      ref(workInProgress.stateNode);
    }
  }
}

看懂了吗？在代码的 completeWork 函数里，最关键的一步就是：

// 将当前节点挂载到父节点的 effectList 上
if (workInProgress.return) {
    workInProgress.return.nextEffect = workInProgress;
}

这一行代码，就是副作用冒泡的灵魂！它把当前节点的“副作用”通过 return 指针，一层一层地传给了父节点。

第四部分：Ref 回调的“冒泡”与执行时机

Ref 回调是理解 completeWork 副作用冒泡的最佳切入点。

大家写过 useRef 吗？或者用过 useEffect 里的 ref 回调吗？比如：

function Parent() {
  const childRef = React.useRef(null);

  useEffect(() => {
    console.log("Parent effect");
    // 这里能拿到 childRef 吗？能，因为 Ref 是冒泡的
    if (childRef.current) {
      console.log("Child exists:", childRef.current);
    }
  }, []);

  return (
    <div>
      <Child ref={childRef} />
    </div>
  );
}

function Child() {
  return <div>我是子组件</div>;
}

为什么在 Parent 的 useEffect 里能拿到 Child 的 DOM 节点？

这就是 completeWork 阶段“副作用冒泡”的杰作。

1. BeginWork 阶段：React 创建了 Child 的 Fiber 节点，创建了这个 Fiber 节点的 stateNode（真实的 <div> DOM 节点）。此时，DOM 已经在内存里了。
2. CompleteWork 阶段：
   • React 首先处理 Child 节点。因为它没有子节点了（或者子节点处理完了），它进入 completeWork。
   • completeWork 发现 Child 有 Ref 标志位。
   • 它执行 Ref 回调：ref(childDivNode)。
   • 关键点：此时，Child 的 stateNode 已经存在了！
   • 然后，completeWork 把 Child 节点挂载到 Parent 的 nextEffect 链表中。
   • 接着，completeWork 处理 Parent 节点。它发现 Parent 也有 Ref 标志位。
   • 它执行 Ref 回调：ref(parentDivNode)。
3. Commit 阶段：React 遍历 effectList（这个列表是从根节点开始的，包含了所有有副作用的节点）。它先处理 Child，再处理 Parent。

所以，当 Parent 的 useEffect 执行时，Child 的 Ref 已经被赋值了。这就是冒泡带来的好处：子节点的状态（DOM 已存在）在父节点处理之前就已经准备好了。

第五部分：DOM 更新的“冒泡”与物理顺序

如果只是逻辑上的冒泡，那还好说。但 React 还有一个更硬核的需求：DOM 节点的物理顺序必须正确。

假设你有这样的结构：

<div id="root">
  <div className="sibling-a">A</div>
  <div className="sibling-b">B</div>
</div>

React 在 Commit 阶段更新 DOM 时，是按照 effectList 的顺序来的。effectList 是怎么排的？是按照 completeWork 遍历的顺序来的。

completeWork 遍历顺序是：左子 -> 右子 -> 兄弟 -> 父节点。

所以，effectList 的顺序很可能是：Child A -> Child B -> Parent。

这意味着，React 会先创建/更新 A，再创建/更新 B，最后更新 Parent。

这符合 DOM 树的结构！因为 Parent 包含了 A 和 B。如果 React 先更新 Parent，再更新 A 和 B，那 A 和 B 就会被插入到 Parent 里面，这是完全正确的。

所以，副作用冒泡保证了 DOM 更新的物理顺序与逻辑层级顺序一致。

第六部分：深入源码 – Switch 语句的艺术

让我们稍微深入一点，看看 React 源码里 completeWork 的 switch 语句。这可是重头戏。

function completeWork(current, workInProgress) {
  const newProps = workInProgress.pendingProps;
  switch (workInProgress.tag) {
    // 1. HostComponent (div, span 等)
    case HostComponent:
      // 处理 DOM 节点的挂载和更新
      popHostContext(workInProgress);
      const rootContainerInstance = getRootHostContainer();
      const type = workInProgress.type;
      // 如果 current 存在（说明是更新），复用 DOM 节点
      if (current !== null && workInProgress.stateNode != null) {
        // 更新 DOM 属性...
      } else {
        // 挂载 DOM 节点
        const instance = createInstance(
          type,
          newProps,
          rootContainerInstance,
          workInProgress,
        );
        // 把 DOM 节点挂载到 Fiber 上
        workInProgress.stateNode = instance;
        // 把副作用标记传递给子节点
        appendAllChildren(workInProgress, instance);
      }
      return null;

    // 2. HostText (纯文本节点)
    case HostText:
      // 处理文本节点的创建和更新
      // ...省略...
      return null;

    // 3. FunctionComponent (普通函数组件)
    case FunctionComponent:
      // ...省略...
      return null;

    // 4. IndeterminateComponent (React.createElement 的情况)
    case IndeterminateComponent:
      // ...省略...
      return null;

    // 5. Portal (ReactDOM.createPortal)
    case Portal:
      // ...省略...
      return null;
  }
}

看这个 switch，它像一个流水线。每个组件类型都有自己的处理方式。

对于 HostComponent（DOM 节点），completeWork 做了两件大事：

1. 创建/复用 DOM：createInstance 或者复用 current.stateNode。
2. 挂载子节点：appendAllChildren。这个函数非常关键！它负责把当前节点的所有子节点（这些子节点在之前的 beginWork 阶段可能已经创建好了 DOM）挂载到当前节点的 DOM 树上。

这再次印证了“父节点在子节点之后完成”的原则。父节点在 completeWork 时，子节点已经完成了 completeWork，DOM 已经存在了，父节点只需要把子节点“挂”在自己身上就行了。

第七部分：EffectList 的构建与 Commit 的消费

咱们前面提到了 effectList。它是 completeWork 阶段构建的，在 commit 阶段被消费。这就像是一个打包清单。

// 简化版 effectList 构建逻辑
function completeWork(current, workInProgress) {
  // ...处理节点本身的逻辑...

  // 如果当前节点有副作用
  if (workInProgress.flags !== NoFlags) {
    // 把它加到父节点的 effectList 里
    if (workInProgress.return) {
      const parent = workInProgress.return;

      // 如果父节点没有 effectList，当前节点就是第一个
      if (!parent.firstEffect) {
        parent.firstEffect = workInProgress;
      } 
      // 如果父节点已经有 effectList，就追加到末尾
      else {
        let lastEffect = parent.lastEffect;
        lastEffect.nextEffect = workInProgress;
        parent.lastEffect = workInProgress;
      }
    }
  }

  // ...返回下一个节点...
}

这就是为什么我们常说 completeWork 是一个自底向上的过程。

• 自底向上：从叶子节点（最深的子组件）开始处理，一直处理到根节点。
• 副作用冒泡：子节点的副作用被收集到父节点的 effectList 中，最终汇聚到根节点的 firstEffect。

到了 Commit 阶段，React 只需要从 rootFiber.firstEffect 开始遍历，依次执行 commitWork 函数。

// Commit 阶段
function commitRoot(root) {
  const firstEffect = root.firstEffect;

  // 遍历 effectList
  let next = firstEffect;
  while (next !== null) {
    // 执行具体的 DOM 更新或副作用
    switch (next.tag) {
      case HostComponent:
        commitWork(next);
        break;
      case HostText:
        commitWork(next);
        break;
      // ...
    }
    next = next.nextEffect;
  }

  // 清除 flags，重置调度器
}

这个设计非常巧妙！它把复杂的渲染逻辑和复杂的 DOM 操作逻辑分开了。

1. Render/Reconcile 阶段（BeginWork + CompleteWork）：只负责计算、创建、标记。不触碰 DOM。这保证了极高的性能。
2. Commit 阶段：只负责根据标记执行 DOM 操作。逻辑简单，但直接操作 DOM，所以不能太频繁。

第八部分：为什么这样设计？（性能与内存）

你可能会问：“老师，为什么 React 不直接在 beginWork 里创建 DOM 呢？还要搞个 completeWork，多此一举啊？”

好问题！这涉及到 React 的性能优化哲学。

1. 内存复用：
   completeWork 的核心任务之一是复用。如果 current 节点和 workInProgress 节点类型相同，React 会复用 current.stateNode（DOM 节点）。
   如果在 beginWork 里就创建 DOM，那每次渲染都要创建新的 DOM 节点，内存压力会爆炸。
   completeWork 就像是“验货”和“打包”，它确保我们只操作必要的节点。

2. 逻辑解耦：
   beginWork 处理的是“结构”和“逻辑”，completeWork 处理的是“物理”和“副作用”。这种分离让 React 可以在 beginWork 阶段非常激进地进行 Diff 算法，而在 completeWork 阶段冷静地进行 DOM 操作。

3. Ref 和 Effect 的时序保证：
   正如我们前面分析的，只有通过 completeWork 的“自底向上”冒泡，才能保证 useEffect 中能拿到最新的 Ref 值，保证 DOM 树的结构完整性。

第九部分：实战演练 – 一个复杂的嵌套组件

咱们来个硬核的实战演练，假设我们有这么一串组件：

// App
//   -> Header (HostComponent div)
//        -> Title (HostComponent h1)
//   -> Content (HostComponent div)
//        -> Text (HostComponent span)
//        -> List (HostComponent ul)
//             -> Item (HostComponent li) x 3

当 React 处理这个树时，completeWork 的执行顺序是这样的：

1. 处理 Item 1：
   • 创建 DOM <li>Item 1</li>。
   • 处理 Ref（如果有）。
   • 标记自己有副作用，挂载到 List 的 nextEffect。
   • 返回 null（没兄弟了）。
2. 处理 Item 2：
   • 创建 DOM <li>Item 2</li>。
   • 处理 Ref。
   • 标记自己有副作用，挂载到 List 的 nextEffect（挂在 Item 1 的后面）。
   • 返回 null。
3. 处理 Item 3：
   • 创建 DOM <li>Item 3</li>。
   • 处理 Ref。
   • 标记自己有副作用，挂载到 List 的 nextEffect。
   • 返回 List（下一个是兄弟节点）。
4. 处理 List：
   • 此时 List 已经有了 nextEffect（Item 1, 2, 3）。
   • List 自己也有副作用（比如更新 class）。
   • 把自己挂载到 Content 的 nextEffect。
   • 返回 Content。
5. 处理 Content：
   • 自己有副作用。
   • 把自己挂载到 App 的 nextEffect。
   • 返回 App。
6. 处理 Header：
   • 把自己挂载到 App 的 nextEffect。
   • 返回 null。

最终，App.firstEffect 指向 Header，Header.nextEffect 指向 Content，Content.nextEffect 指向 List，List.nextEffect 指向 Item 1，以此类推。

Commit 阶段执行顺序：Header -> Content -> List -> Item 1 -> Item 2 -> Item 3。

这个顺序完美地覆盖了 DOM 树的层级关系，同时保证了子节点的副作用在父节点之前执行。

第十部分：进阶话题 – 子节点更新与父节点副作用

咱们再深入一点。如果父节点更新了，子节点没更新，会怎么样？

比如：

function Parent() {
  const [count, setCount] = React.useState(0);
  return (
    <div>
      <span>Count is: {count}</span>
      <Child />
    </div>
  );
}

当 count 变化时：

1. beginWork 会发现 div 标签变了（span 变成了 span，但文本变了），标记 Update。
2. beginWork 发现 Child 没变，标记 NoFlags。
3. completeWork 处理 Child：发现没副作用，直接返回。
4. completeWork 处理 div：
   • 发现自己有 Update 标志。
   • 执行 DOM 更新（修改文本节点内容）。
   • 把自己挂载到父节点的 nextEffect。

如果父节点更新了，子节点没更新，那么子节点就不会出现在 effectList 里。Commit 阶段就不会处理子节点。这极大地减少了不必要的 DOM 操作。

第十一部分：Ref 的特殊处理与副作用冒泡的边界

最后，咱们聊聊 Ref。

Ref 是一个特殊的存在。它既不是 DOM 的属性更新，也不是文本的插入。它是一个回调函数。

在 completeWork 里，Ref 标志位通常被单独处理。

// React 源码片段
if (workInProgress.flags & Ref) {
  if (current !== null && workInProgress.ref !== null) {
    // Ref 更新逻辑...
  } else if (workInProgress.ref !== null) {
    // Ref 挂载逻辑
    const ref = workInProgress.ref;
    const instance = workInProgress.stateNode;
    ref(instance);
  }
}

注意这里的条件 current !== null。这说明，只有当节点从无到有（挂载）或者从有到有（更新）时，Ref 回调才会被触发。

如果是删除节点呢？
completeWork 也会处理删除。它会把被删除的节点标记为 Deletion，然后把它挂载到父节点的 nextEffect 链表里。在 Commit 阶段，React 会执行 commitDeletion，调用 Ref 回调，并传入 null。

这再次印证了“冒泡”逻辑的完整性：无论节点是挂载、更新还是删除，它都会被 completeWork 处理，并按顺序加入到父节点的副作用队列中。

总结：副作用冒泡的精髓

好了，各位同学，咱们今天的讲座马上就要接近尾声了。

回顾一下，我们今天深入探讨了 React 的 completeWork 阶段，以及那个听起来很高深莫测的“副作用冒泡”原理。

1. 角色定位：completeWork 是渲染过程的“收尾者”，负责把 Fiber 节点转化为物理 DOM，并处理副作用。
2. 核心机制：它通过遍历 return 指针，实现了自底向上的后序遍历。先子后父，先叶子后根。
3. 副作用收集：通过 nextEffect 链表，将子节点的副作用一层层“冒泡”到父节点，最终汇聚到根节点。
4. 实际意义：
   • DOM 顺序保证：确保 DOM 更新的物理顺序与逻辑层级一致。
   • Ref 时序保证：保证父组件的 useEffect 能拿到子组件最新的 DOM 节点。
   • 性能优化：通过复用 stateNode 和精准标记 flags，避免不必要的 DOM 操作。

所以，下次当你看到 React 飞快地渲染页面，或者你的 useEffect 按照预期顺序执行时，别忘了感谢那个默默无闻的 completeWork 函数，以及它所代表的副作用冒泡机制。

它就像是一个尽职尽责的管家，把家里所有的琐事（副作用）都安排得井井有条，最后才把总账（DOM 更新）交给主人（Commit 阶段）去签字画押。

好了，今天的代码就讲到这里。希望大家在以后的 React 开发中，能对这些底层原理有更深的理解。如果大家有什么疑问，欢迎在评论区留言，咱们下次再见！

（此处应有掌声，以及代码编辑器疯狂敲击的声音）