React 的“送葬仪式”：深度剖析 commitMutationEffects 与节点卸载逻辑

各位好，我是你们的老朋友。今天我们不聊那些花里胡哨的 Hooks，也不谈怎么把性能优化到极致的渲染帧率，我们来聊点“悲伤”的话题——删除。

在 React 的世界里，添加节点就像是在花园里种花，那是充满希望和生命力的；而删除节点，就像是一场葬礼，必须得有条不紊，得有仪式感，得让每一个逝去的灵魂（组件）都体面地离开。

这个负责执行葬礼仪式的核心部门，就是 commitMutationEffects。

如果你以为 React 只是简单地遍历一下树，把该删的 DOM 节点 remove() 掉，那你就太小看这个库了。React 的删除逻辑，是一套精密设计的、基于后序遍历的、包含生命周期回调和副作用清理的复杂系统。它不仅要处理 DOM 的物理移除，还要处理 Fiber 树的逻辑断连，更要确保 useEffect 的清理函数在正确的时机被调用。

准备好了吗？我们要潜入 React 源码的深处，去看看它是如何处理这场“送葬仪式”的。

---

第一幕：从“协调”到“提交”

在深入 commitMutationEffects 之前，我们需要先搞清楚它在 React 整个生命周期中的位置。

想象一下，你正在装修房子。

1. Render（协调）阶段：这是你的大脑。你在脑子里想：“哎呀，客厅太乱了，得扔掉沙发，换一张大的。”你画了一张图纸，把要扔的沙发标记了一个红叉，把新沙发标记了一个绿勾。这一步是异步的，如果用户疯狂点击，React 会打断你，让你重新画图。
2. Commit（提交）阶段：这是你的双手。图纸画好了，现在轮到真的动手了。你开始扔沙发，搬新沙发，打扫卫生。

commitMutationEffects 就是在 Commit 阶段 中，负责处理所有 Mutation（变更） 的核心函数。

它的主要任务就是遍历刚才画好的那张“图纸”（Fiber 树），根据上面的标记（Flags），对 DOM 节点进行物理操作，或者对组件实例进行逻辑销毁。

第二幕：识别“死者”——MutationMask

React 是怎么知道哪个节点该死呢？靠的是每个 Fiber 节点身上的 flags。

在 commitMutationEffects 开始工作前，React 已经通过 reconcileChildren（协调子节点）阶段，给所有受影响的 Fiber 节点打上了标记。常见的标记有：

• Placement：新加的（插入 DOM）。
• Deletion：要删的（删除 DOM）。
• Update：要更新的（修改 DOM 属性/文本）。
• Hydration：水合（SSR 相关，暂且不表）。

commitMutationEffects 的核心循环就像是一个尽职尽责的殡仪馆馆长，它手里拿着一张长长的名单（finishedWork.nextEffect），一个接一个地检查这些节点：

// commitMutationEffects.js 的核心伪代码
function commitMutationEffects(root, finishedWork) {
  let nextEffect = finishedWork.nextEffect;

  while (nextEffect !== null) {
    const flags = nextEffect.flags;

    // 1. 处理删除逻辑
    if ((flags & Placement) !== NoFlags) {
      commitPlacement(nextEffect);
    }
    if ((flags & Deletion) !== NoFlags) {
      commitDeletion(nextEffect, root);
    }
    if ((flags & Update) !== NoFlags) {
      commitUpdate(nextEffect);
    }

    // ... 其他处理

    // 移动指针，去下一个受害者
    nextEffect = nextEffect.nextEffect;
  }
}

注意看，这里有个关键的逻辑判断顺序。虽然代码里是顺序写的，但在真正的实现中，Deletion（删除） 是最特殊、最复杂的，因为它涉及到子树的递归处理。但为了方便理解，我们先把 Deletion 单独拎出来讲。

第三幕：葬礼的顺序——为什么是后序遍历？

这是 React 删除逻辑中最迷人、也是最反直觉的地方。

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

function App() {
  return (
    <Parent>
      <ChildA />
      <ChildB />
    </Parent>
  );
}

现在，我们要把 ChildA 删掉。React 的 Fiber 树结构大概是这样的：

• Parent (flags: Deletion)
  • ChildA (flags: Deletion)
  • ChildB (flags: Update)

React 是先删 Parent，还是先删 ChildA？

答案是：先删 ChildA，再删 Parent。

这就是 后序遍历 的精髓。为什么？

1. useEffect 的清理函数需要父组件存在

这是最核心的原因。useEffect 的清理函数（cleanup function）是在组件卸载时运行的。React 规定，子组件的清理函数必须先于父组件的清理函数运行。

如果父组件先卸载了，它的 useEffect 已经跑完了，清理函数也执行了。这时候再执行子组件的清理函数，虽然技术上可能实现（因为 Fiber 树还在），但这违背了 React 的生命周期语义。

所以，React 在处理 commitMutationEffects 时，会递归地先处理子节点，直到叶子节点，再回过头来处理父节点。

2. DOM 结构的物理逻辑

从 DOM 的角度看，子节点是挂载在父节点之下的。你要移除一个节点，必须先移除它内部的子节点，才能移除它自己。这就像你要把一棵树连根拔起，必须先剪断枝叶。

第四幕：commitDeletion —— 深度剖析

现在，让我们深入 commitDeletion 函数。这可是重头戏。

// commitMutationEffects.js
function commitDeletion(finishedWork, committedFiber) {
  // 第一步：递归遍历子树，标记并处理所有子节点的卸载
  // 注意：这里使用的是 finishedWork.child，因为是后序遍历，先处理孩子
  commitDeletionEffects(finishedWork.child, committedFiber);

  // 第二步：真正执行卸载逻辑
  // 这一步会处理副作用清理和 DOM 移除
  unmountHostComponent(finishedWork, committedFiber);
}

4.1 递归地狱：commitDeletionEffects

React 需要递归地找到所有需要被卸载的子节点。这不仅仅是遍历 Fiber 链表，还要处理兄弟节点。

function commitDeletionEffects(parentFiber, committedFiber) {
  let nextEffect = parentFiber.child;

  while (nextEffect !== null) {
    // 递归处理子节点
    commitDeletionEffects(nextEffect, committedFiber);

    // 处理兄弟节点
    nextEffect = nextEffect.sibling;
  }
}

这个循环会一直向下钻，直到遇到 null（叶子节点），然后回溯。在这个过程中，React 会检查每个子节点是否也有 Deletion 标记。如果有，它会再次调用 commitDeletion。

4.2 生命周期的告别：unmountComponentAtNodeRoot

当递归结束，所有子节点都处理完了，现在轮到当前节点 finishedWork 了。React 会调用 unmountComponentAtNodeRoot（注意：这只是个伪代码函数名，实际源码中逻辑更分散，涉及 commitBeforeMutationEffects 和 commitMutationEffects 的交互）。

这一步主要干了两件事：

1. 调用 componentWillUnmount：这是旧的生命周期，现在已经被废弃了，但逻辑还在。
2. 调用 useEffect 的清理函数：这是现代 React 的核心。useEffect(() => { ... }, []) 中的清理函数会被调用。

代码示例：清理函数的执行时机

function Parent() {
  useEffect(() => {
    console.log("Parent: Mount");
    return () => {
      console.log("Parent: Unmount Cleanup"); // 父组件清理函数
    };
  }, []);

  return (
    <Child />
  );
}

function Child() {
  useEffect(() => {
    console.log("Child: Mount");
    return () => {
      console.log("Child: Unmount Cleanup"); // 子组件清理函数
    };
  }, []);
}

当父组件卸载时，控制台输出顺序一定是：

1. Child: Unmount Cleanup
2. Parent: Unmount Cleanup

这就是 commitDeletionEffects 递归遍历带来的必然结果。React 必须确保子组件先“走”，父组件才能“走”。

第五幕：DOM 的物理移除与 Fiber 树的“断舍离”

递归处理完副作用（生命周期）之后，真正残酷的时刻到了——物理移除 DOM 节点。这部分逻辑主要在 unmountHostComponent 中。

5.1 移除 DOM

React 会找到对应的 DOM 节点（如果是 HostComponent，比如 <div>），然后执行原生的 remove() 方法。

// FiberNode.js (伪代码)
function unmountHostComponent(finishedWork, committedFiber) {
  const instance = finishedWork.stateNode;

  // 1. 如果是 HostComponent (div, span等)
  if (instance !== null) {
    // 执行 DOM 移除
    // 这里的逻辑稍微有点绕，React 会处理一下 diff，确保只移除必要的节点
    // 比如，如果父节点也要删，React 可能会直接把子节点也删了，减少 DOM 操作

    // 简单理解：把 DOM 从父节点上拔下来
    removeChild(instance, committedFiber.stateNode);
  }

  // 2. 清理 ref
  // ref 是 React 给开发者留的一个后门，用来访问 DOM
  // 如果组件卸载了，ref 必须置空，否则开发者拿到的就是 null 或者报错
  if (finishedWork.ref !== null) {
    const currentRef = finishedWork.ref;
    if (typeof currentRef === 'function') {
      currentRef(null); // 调用 ref 回调，传入 null
    } else {
      currentRef.current = null; // 重置 ref.current
    }
  }
}

5.2 断开 Fiber 链表

DOM 移除了，Fiber 树的逻辑链表也得断开。这是最容易被忽略的一步。

在 React 的 Fiber 树中，每个节点都有 return 指针指向父节点。

// FiberNode.js
child.return = parent;

当删除发生时，React 必须把这个指针断开。这样，当 GC（垃圾回收）机制运行时，或者当 React 继续遍历树时，它就再也找不到这个被删除的节点了。

虽然 commitMutationEffects 的主循环是通过 nextEffect 链表来遍历的，但在实际源码中，commitDeletion 会在递归过程中，把子节点的 nextEffect 指针指向上一个兄弟节点，形成一个临时的遍历链表，直到处理完所有子节点。处理完后，这个链表会被断开，因为节点已经死了。

第六幕：代码实战——一个完整的删除流程模拟

为了让你彻底明白，我们来手写一个简化版的 commitMutationEffects，模拟删除 App 组件中的 ChildA。

假设 Fiber 树结构如下：

App (Deletion)
├── ChildA (Deletion)
└── ChildB (Update)

执行流程：

1. 进入 commitMutationEffects 循环

   • nextEffect 指向 App。
   • 检测到 App.flags 有 Deletion。
   • 调用 commitDeletion(App)。

2. 递归处理子节点

   • commitDeletion(App) 调用 commitDeletionEffects(App.child)，也就是 ChildA。
   • 递归 ChildA：
     • 检查 ChildA.flags，发现也是 Deletion。
     • 调用 commitDeletion(ChildA)。
     • 递归 ChildA：没有子节点了，返回。
     • 处理 ChildA 的生命周期：
       • 调用 ChildA 的 useEffect 清理函数。
       • 输出："ChildA: Cleanup"。
     • 处理 ChildA 的 DOM：
       • 找到 DOM 节点 #child-a，执行 remove()。
     • 处理 ChildA 的 Ref：
       • 断开 ChildA.return 指针。

3. 回到 ChildA，继续递归兄弟节点

   • ChildA 还有兄弟节点 ChildB。
   • 调用 commitDeletion(ChildB)。
   • 递归 ChildB：
     • 检查 ChildB.flags，发现是 Update，不是 Deletion。
     • 跳过删除逻辑，直接进入 commitWork 处理更新。
   • 处理 ChildB 的 DOM：
     • 更新 ChildB 的 DOM 属性。
   • 回到 App
     • ChildA 的兄弟节点处理完了。
     • 现在处理 App 自己。
     • 处理 App 的生命周期：
       • 调用 App 的 useEffect 清理函数。
       • 输出："App: Cleanup"。
     • 处理 App 的 DOM：
       • 找到 DOM 节点 #app，执行 remove()。
     • 处理 App 的 Ref：
       • 断开 App.return 指针。

最终结果：

1. ChildA 的清理函数先跑。
2. ChildB 的 DOM 属性更新了（因为它是 Update，不是 Deletion）。
3. App 的清理函数最后跑。
4. App 和 ChildA 的 DOM 节点都被从 DOM 树中物理移除了。

第七幕：进阶话题——Placement 与 Deletion 的“相爱相杀”

你可能会问：“React 怎么知道我是在移动节点，而不是删除再加？”

这是一个非常经典的问题，也是 React 性能优化的一个黑科技。

在 commitMutationEffects 的主循环中，React 会检查 Placement 和 Deletion 标记。

如果一个节点同时有 Placement（要加）和 Deletion（要删）标记，React 会非常聪明地决定：

1. 如果是移动节点：React 不会执行 removeChild（DOM 移除），而是直接调用 insertBefore 或 appendChild 将节点移动到新位置。这比删除再插入性能高得多，因为不需要重新创建 DOM 节点，也不需要重新触发挂载生命周期。
2. 如果是真正删除：React 才会执行 removeChild。

这意味着，在 commitMutationEffects 的执行过程中，如果一个节点被标记为 Placement，React 会优先把它当作“移动”处理。只有当它被标记为 Deletion 时，才会把它当作“死亡”处理。

第八幕：总结——送葬师的内心独白

回过头来看 commitMutationEffects，它就像一位冷静、专业、甚至有点强迫症的送葬师。

1. 它很细心（递归）：它不会因为父节点死了就不管孩子。它会顺着 Fiber 树的脉络，一层层往下挖，直到把所有的“副作用清理函数”都跑完。
2. 它守规矩（后序遍历）：它严格遵循子先父后的原则，确保 useEffect 的清理逻辑符合我们的直觉。
3. 它很高效（DOM 操作）：它尽量减少 DOM 的重绘和重排，能移除就移除，能复用就不重建。
4. 它很负责（Ref 清理）：它记得在节点断气前，把那个想偷窥 DOM 的 ref 给关掉，不让它对着空气乱叫。

所以，当你写代码时，特别是涉及到清理副作用时，一定要记住 React 这个“送葬师”的脾气。如果你在子组件的 useEffect 里清理了什么，确保父组件的清理函数是最后才执行的。如果你忘了清理，React 不会帮你，它会默默地把你的垃圾留在原地，直到内存泄漏找上门来。

这就是 commitMutationEffects，一段关于删除、死亡与重生的代码之旅。希望这堂课能让你对 React 的内部机制有更深的理解。下次当你看到一个组件被销毁时，你会感谢 React 在后台为你精心准备的这场告别仪式。