React 回收机制：Fiber 树卸载过程中的循环引用切断与全局内存清理逻辑分析

各位同学，大家好。今天我们不聊“怎么用 React 写出高阶组件”，也不聊“Hooks 的边界情况”，我们来聊聊一个稍微有点“丧”的话题——React 的“葬礼”。

想象一下，你的 React 应用就像一个巨大的、繁忙的豪宅。每个组件就是豪宅里的一个房间。有时候，因为主人要搬家了，或者房子要拆了，我们需要把整个房间——甚至整栋楼——都清空。

这时候，如果清理不干净，就会发生灾难。比如，门没锁，风把外面的垃圾吹进来了；比如，墙纸撕下来了，但背后的钉子还死死地钉在墙上，把垃圾回收器（GC）都卡住了。

在 React 的世界里，这栋豪宅叫 Fiber 树。而我们要进行的这场“清理仪式”，就是 卸载。今天，我们就来扒开 React 的裤裆（比喻），看看它是如何在卸载过程中，切断那些乱七八糟的“循环引用”，并把内存里的垃圾干干净净地扫出去的。

准备好了吗？让我们开始这场关于内存、引用和断舍离的深度讲座。

---

第一幕：Fiber 树的罗生门

在深入清理之前，我们得先搞清楚 React 为什么需要这么费劲地去清理。这得从 Fiber 的结构说起。

在 React 15 之前，DOM 节点和组件是一一对应的，那叫一个简单粗暴。但后来 React 想要实现“并发渲染”、“时间切片”，于是它搞出了 Fiber 架构。

Fiber 本质上是一个 JavaScript 对象。为了维护组件树的结构，每个 Fiber 节点都通过三个指针互相链接：

1. child：指向第一个子节点。
2. sibling：指向下一个兄弟节点（也就是右边那个）。
3. return：指向父节点（也就是上面那个）。

这就形成了一个单向链表结构。

但是，React 是怎么把 Fiber 树和真实的 DOM 树对应起来的呢？这里有个秘密武器：stateNode。

每个 Fiber 节点都有一个 stateNode 属性。对于类组件，它是组件实例；但对于函数组件，这个 stateNode 指向的是真实的 DOM 节点（或者说是 DOM 节点的占位符）。

这就形成了一个死循环（或者说是一个双向绑定）：

// 伪代码示例：Fiber 节点的结构
const fiberNode = {
  stateNode: document.createElement('div'), // 真实的 DOM 节点
  child: null,
  return: parentFiberNode, // 指向父节点
  // ... 其他属性
};

// 同时，真实的 DOM 节点上也挂载了 current 指针
fiberNode.stateNode._reactInternalFiber = fiberNode;

看到了吗？这就是问题的根源。

1. Fiber 引用了 DOM。
2. DOM 也通过 _reactInternalFiber 引用了 Fiber。
3. Fiber 的 return 指针又把 Fiber 们连成了一棵树。

这就是所谓的“循环引用”。如果你只是把 Fiber 对象置为 null，但没管 DOM，GC（垃圾回收器）看到 DOM 上还有 _reactInternalFiber 的引用，就会说：“嘿，这个 DOM 还有人用呢，我不能删。” 于是，内存泄漏发生了。

所以，卸载过程的核心任务就是：物理上销毁 DOM，逻辑上切断 Fiber 与 DOM 的联系，并递归地处理所有子节点。

---

第二幕：葬礼的流程图

React 的卸载过程发生在 Commit 阶段 的 Before Mutation（变异前） 和 Mutation（变异） 两个子阶段。这听起来很玄学，但其实非常符合人类逻辑。

整个流程就像是一场送别会，分三个步骤进行：

1. Ref 清理（Before Mutation）：在 DOM 被移除之前，先处理 ref。这是为了防止在 DOM 删除的瞬间，ref 回调函数试图访问一个已经不存在的 DOM 节点。
2. DOM 移除与断开连接（Mutation）：把 DOM 节点从父节点上摘下来，把 Fiber 节点之间的 return 链条剪断。
3. 事件监听器清理与子节点处理（Layout）：把挂在 DOM 上的事件监听器拔掉，然后递归处理剩下的子节点。

我们来看源码级别的逻辑（基于 React 18/19 的理解）。

---

第三幕：第一步——Ref 的最后回眸

当一个组件开始卸载时，React 会遍历 Fiber 树。如果一个节点有 RefCleanup 的标记，它就会进入 commitBeforeMutationLifeCycles 阶段。

为什么叫 Before Mutation？因为这时候 DOM 还在，但 React 需要在它消失之前做点最后的检查。

这里的核心逻辑是快照机制。

// 模拟 commitBeforeMutationLifeCycles 的核心逻辑
function commitBeforeMutationLifeCycles(fiber) {
  // 1. 如果是类组件，先执行 componentWillUnmount
  if (fiber.tag === ClassComponent) {
    const instance = fiber.stateNode;
    if (instance.componentWillUnmount) {
      instance.componentWillUnmount();
    }
  }

  // 2. 处理 ref 的清理
  if (fiber.effectTag & RefCleanup) {
    const nextEffect = fiber;
    do {
      const refCleanup = nextEffect.ref;
      if (refCleanup !== null) {
        // 关键点：我们在 DOM 还在的时候，先调用 ref 回调
        // 传入的参数是 DOM 节点本身
        if (typeof refCleanup === 'function') {
          refCleanup(null); // 传入 null 表示 DOM 节点即将被销毁
        } else {
          refCleanup.current = null;
        }
      }
      nextEffect = nextEffect.nextEffect;
    } while (nextEffect !== null);
  }
}

为什么要这么做？

试想一下，你的代码里有一个 useRef：

function MyComponent() {
  const domRef = useRef(null);

  useEffect(() => {
    // 假设我们在挂载时把 DOM 节点存到了全局变量里（这是坏习惯，但确实会发生）
    window.debugRef = domRef.current;
  }, []);

  return <div ref={domRef} />;
}

如果在 refCleanup 阶段不先调用 ref(null)，而是直接删了 DOM，那么 domRef.current 就会变成 null，但如果你在卸载组件的 useEffect 里还试图访问 window.debugRef，你就拿到了一个“幽灵”引用，或者是一个已经被删掉的 DOM 节点。

通过在 Before Mutation 阶段调用 ref(null)，React 帮你把那个“幽灵”给封印了，防止后续的逻辑去触碰它。

---

第四幕：第二步——物理断骨与逻辑切链

这是最暴力、最关键的一步：DOM 节点的移除和Fiber 链条的剪断。

在 commitMutationEffects 阶段，React 会遍历 Effect List（副作用列表）。对于被标记为 Deletion（删除）的节点，它会执行以下操作：

1. 物理移除 DOM

// 模拟 commitMutationEffects 中的删除逻辑
function commitMutationEffects(fiber) {
  // ... 遍历 effect list 的逻辑 ...

  if (fiber.effectTag & Deletion) {
    // 找到对应的 DOM 节点
    const current = fiber.stateNode;

    // 关键操作：从父 DOM 节点中移除自己
    if (current !== null) {
      const parentNode = current.parentNode;
      if (parentNode !== null) {
        parentNode.removeChild(current);
      }
    }

    // ... 继续处理子节点 ...
  }
}

这一步非常直接：parentNode.removeChild(current)。DOM 节点在浏览器里彻底消失了。

2. 逻辑切链

光删 DOM 不够，React 还得把 Fiber 树里的“绳子”剪断。

还记得 Fiber 节点的结构吗？child, sibling, return。

当 Fiber A 删除了它的子节点 Fiber B 之后，React 会做一件事：把 Fiber B 的 return 指针置为 null。

// 模拟逻辑
if (fiber.effectTag & Deletion) {
  // ...
  // 此时 fiber 是被删除的那个子节点（比如 B）

  // 关键操作：切断父子关系
  if (fiber.return !== null) {
    fiber.return = null;
  }
}

为什么要这么做？

这是一个非常微妙的内存优化点。

假设 Fiber A 是一个父组件，Fiber B 是它的子组件。如果 Fiber A 被卸载了，那么 Fiber B 必须死。但是，React 的卸载算法通常是自底向上或者深度优先进行的。

如果在处理 Fiber B 的时候，React 还持有对 Fiber A 的引用（比如通过父组件的 return 指针），那么当 Fiber B 被清理完毕，垃圾回收器检查到 Fiber A 还有引用（因为 Fiber A 还在 effect list 里），它就不会回收 Fiber A。

但是，如果 Fiber A 已经被标记为删除了，它的 return 指针已经被置空了，那么当 Fiber B 被回收时，它就成了一个“孤魂野鬼”。虽然 React 的调度器会最终清理掉这个孤魂野鬼，但为了极致的内存管理，切断 return 链条意味着彻底的“断舍离”。

这就像你搬家，把箱子扔了，你还得把贴在箱子上的快递单撕下来。撕了单子，垃圾回收器才能确认这个箱子是真的垃圾。

---

第五幕：第三步——拔掉插头

DOM 没了，绳子断了，接下来要处理那些挂在 DOM 上的“插头”——事件监听器。

在 React 事件委托机制下，事件监听器是绑定在 DOM 根节点上的。但是，React 内部维护了一个映射表，记录了哪个 DOM 节点对应哪个 Fiber 节点。

在 commitLayoutEffects 阶段，React 会做最后的收尾工作。虽然具体的 removeEventListener 逻辑是在 Fiber 节点创建时注册的，但在卸载时，React 需要确保没有残留的事件监听器还在试图触发那些已经不存在的组件逻辑。

更重要的是，这一步会触发 useEffect 的清理函数。

这是 React 内存管理的“重头戏”。

function MyComponent() {
  useEffect(() => {
    // 这是一个“脏活累活”的回调
    console.log("组件挂载，开始干活");

    // 假设我们创建了一个定时器，或者一个全局订阅
    const timer = setInterval(() => {
      console.log("我在干活...");
    }, 1000);

    // 返回清理函数
    return () => {
      console.log("组件卸载，停止干活！");
      clearInterval(timer);
    };
  }, []);

  return <div>我要被删除了</div>;
}

当这个组件被卸载时，React 会在 commitLayoutEffects 阶段执行返回的清理函数。

这里有个非常坑的陷阱：

如果你在 useEffect 的清理函数里，试图访问组件的 state 或者 props，会发生什么？

function MyComponent() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      // 危险！此时组件可能已经卸载了，state 是什么鬼都不知道
      // 如果这个闭包捕获了 state，它可能是一个过期的状态值
      console.log(count); 
    }, 1000);

    return () => {
      clearInterval(timer);
      // 如果这里的闭包捕获了旧的 state，这里可能读取到的是垃圾数据
      // 但只要不报错，React 就不会报错
    };
  }, []);

  return <div>{count}</div>;
}

React 的卸载机制确保了清理函数执行的时候，组件的状态可能已经被重置（对于函数组件，状态对象可能已经被 GC 回收了）。React 并不保证 useEffect 清理函数里的 this 或 state 是有效的，它只保证函数会被执行。

但是！ 如果你的清理函数里还持有对外部变量的引用，而这些外部变量引用了组件内部的数据，你就制造了一个延时炸弹。

这就是为什么 React 官方文档反复强调：在 useEffect 的清理函数里，不要依赖组件的状态。

---

第六幕：内存泄漏的幽灵——闭包陷阱

回到我们的主题：循环引用切断与全局内存清理。

很多同学以为 React 只要删了 DOM 节点，内存就干净了。错！大错特错。React 的 Fiber 节点本身就是一个巨大的 JS 对象，包含大量的闭包。

function ParentComponent() {
  const [visible, setVisible] = useState(true);

  if (!visible) return null; // 这里组件直接返回 null，组件实例销毁

  return (
    <ChildComponent 
      onClick={() => {
        // 注意这个箭头函数！它是一个闭包！
        // 它捕获了 ParentComponent 的作用域
        console.log("点击了子组件");
      }} 
    />
  );
}

上面的代码，当 visible 变为 false 时，React 会卸载 ParentComponent。但是，ChildComponent 的 onClick 事件处理器里捕获的那个箭头函数，依然存在。

如果 ChildComponent 被卸载了，但它的 onClick 被挂载到了某个全局变量、或者父组件依然持有的某个数组里，那么：

1. ParentComponent 的函数体（闭包环境）被销毁了。
2. 但是，那个箭头函数还在。
3. 当你点击事件触发时，试图访问 ParentComponent 的变量……崩溃。

这就是 React 卸载机制必须彻底切断引用的原因。

在源码层面，React 会递归遍历所有的子 Fiber 节点，执行 unmountFiberAtNode。在这个过程中，它会：

1. 移除 DOM：物理删除。
2. 清理 Ref：调用 ref(null)。
3. 移除事件监听器：虽然 React 的事件系统是委托的，但内部会标记该节点为非活跃状态。
4. 递归：如果子节点还有子节点，继续重复上述步骤。

只有当整棵树都遍历完了，根节点的 current 指针被置空，整个组件树才算是真正“死透了”。

---

第七幕：实战演练——如何复现与修复

为了证明我们讲的这些理论，我们来写一段代码，故意制造内存泄漏，然后看看 React 是怎么“收尸”的。

场景：制造泄漏

// 恶意的组件
function LeakyComponent() {
  const [count, setCount] = useState(0);

  // 在挂载时，把组件实例（虽然函数组件没有实例，但作用域是实例）存到全局
  useEffect(() => {
    window.leakyRef = { count, component: LeakyComponent };

    const interval = setInterval(() => {
      // 这个闭包会一直持有 LeakyComponent 的状态
      console.log("LeakyComponent is alive:", count);
    }, 1000);

    return () => {
      // 卸载清理
      clearInterval(interval);
      console.log("LeakyComponent unmounted");
    };
  }, []);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>
      <button onClick={() => {
        // 强制卸载自己
        LeakyComponent.unmount();
      }}>Unmount</button>
    </div>
  );
}

// 模拟 React 的 unmount 方法
LeakyComponent.unmount = () => {
  // 这里假设我们有一个全局的 root，并调用 unmountComponentAtNode
  // 在真实 React 中，这是 FiberRootNode 的逻辑
  console.log("Triggering unmount...");
  // 实际代码: ReactDOM.unmountComponentAtNode(document.getElementById('root'));
};

React 的处理逻辑（脑补源码）：

当你点击“Unmount”时，React 开始工作：

1. Commit Before Mutation：

   • 发现 LeakyComponent 的 Fiber 节点。
   • 发现 RefCleanup 标记。
   • 执行 ref(null)。此时，window.leakyRef 会被置为 null（如果 ref 是函数）或者 current 被置空。

2. Commit Mutation：

   • 找到对应的 DOM 节点 <div>。
   • 执行 parentNode.removeChild(div)。DOM 没了。
   • 执行 fiber.return = null。Fiber 节点成了孤儿。

3. Commit Layout：

   • 执行 useEffect 的清理函数。
   • clearInterval(interval) 被调用。
   • 关键点：此时，虽然 window.leakyRef 可能被清空了，但如果你的代码里有什么地方还强引用了这个组件（比如某个闭包里），React 的调度器会标记这个 Fiber 节点为“垃圾”。当 GC 来的时候，它会回收它。

修复泄漏

如果你在 useEffect 的清理函数里，试图访问 window.leakyRef，那你就完了，因为 window.leakyRef 已经被 React 在 RefCleanup 阶段清理掉了。

正确的做法是：

useEffect(() => {
  const interval = setInterval(() => {
    // 不要在清理函数里访问外部引用！
    // 如果必须访问，确保引用是稳定的，或者传递最新数据
  }, 1000);

  return () => {
    clearInterval(interval);
    // 不要写：console.log(window.leakyRef.count); 
    // 因为这可能是 undefined
  };
}, []);

---

第八幕：深度剖析——全局内存清理的幕后黑手

我们最后要谈谈“全局内存清理逻辑”。这听起来很玄乎，其实就是垃圾回收器（GC）的工作。

JavaScript 的 GC 机制主要基于引用计数和标记-清除。

React 在卸载过程中，实际上是在为 GC 做准备。

1. 断开强引用：React 把 Fiber 节点从 DOM 上剥离，把 DOM 从 Fiber 上剥离。这是切断强引用。
2. 置空引用：React 把 stateNode 置为 null（在类组件卸载时），把 ref 置为 null。
3. 递归清理：React 确保没有子节点被遗漏。

为什么这很重要？

在 React 16 之前，有时候因为调度器的问题，组件树没有完全卸载，导致内存占用居高不下。现在的 Fiber 架构通过 Effect List（副作用列表）和 Commit 阶段的严格顺序，确保了卸载的原子性。

Effect List 是一个神奇的东西。React 会在渲染阶段构建一棵树，然后生成一个线性列表（链表），这个列表记录了哪些节点有副作用（插入、更新、删除）。

卸载时，React 就按照这个列表的顺序，从后往前（或者从前往后，取决于实现）进行清理。这保证了：

• 子节点一定在父节点之前被清理。
• DOM 节点一定在 Fiber 节点之前被清理。
• 事件监听器一定在组件逻辑之前被清理。

这种严格的顺序，就是 React 能够切断“循环引用”的保证。

---

第九幕：总结与反思

好了，同学们，我们的讲座快要结束了。

回顾一下，React 在卸载组件树时，并不是简单地执行 node.remove()。它是一场精心编排的手术：

1. Ref 清理：在尸体（DOM）消失前，先给遗像（Ref）盖上白布。
2. DOM 移除：物理上从 DOM 树中摘除节点。
3. 逻辑切链：把 Fiber 树的父子关系剪断，防止残留引用。
4. 事件与清理函数：拔掉插头，执行最后的倒计时（useEffect cleanup）。

这整个过程，就是 React 对“循环引用”的一次全面围剿。它通过维护 Fiber 树和 DOM 树的双向映射，并在卸载阶段逆序切断这些映射，确保了垃圾回收器能够顺利地回收内存。

对于我们开发者来说，理解这个过程有什么用？

它告诉我们：

• 不要在 useEffect 里存全局变量：因为 React 会帮你清理，你存了反而污染全局。
• 不要在 useEffect 清理里访问组件状态：因为组件状态可能已经被回收了。
• 理解生命周期：useEffect 的清理函数是组件“死亡”时的最后一口气，要好好利用它来做善后工作。

最后，我想说的是，React 的 Fiber 架构就像是一个极其负责的管家。当你决定不再需要这栋豪宅时，他会亲自帮你拆掉地板，砸烂墙壁，把钉子拔出来，把垃圾扫进袋子里，直到房子变得空空如也，一尘不染。

这就是 React 的回收机制，一场关于代码、内存与生命的断舍离。希望大家在未来的 React 开发中，能像 React 一样，学会及时清理自己的内存，保持代码的清爽与高效。

下课！