解析 ‘Heap Snapshots’ 中的 React 节点：如何从内存快照中找到那些被闭包扣留的 Fiber 节点？

在单页应用（SPA）盛行的今天，前端应用的内存管理变得日益重要。尤其是对于像 React 这样高度动态的框架，不当的资源管理很容易导致内存泄漏，进而影响应用的性能和用户体验。其中，被闭包（Closure）不经意间扣留的 React Fiber 节点，是这类内存泄漏中一个既常见又隐蔽的问题。

本讲座旨在深入探讨如何利用 Chrome DevTools 的内存快照功能，精准定位并解析这些被闭包“困住”的 Fiber 节点。我们将从 React Fiber 架构的基础讲起，逐步深入到内存快照的捕获与分析，并通过具体的代码示例和详细的分析步骤，揭示闭包如何导致 Fiber 节点泄漏，并提供有效的解决方案。

---

第一章：内存泄漏在 React 应用中的重要性与挑战

1.1 为什么关注内存泄漏？

在现代 Web 应用中，用户期望流畅、响应迅速的体验。内存泄漏会逐渐消耗系统资源，导致：

• 性能下降：应用响应变慢，动画卡顿，甚至出现页面无响应。
• 用户体验差：长时间使用后，用户可能需要刷新页面才能恢复正常，甚至导致浏览器崩溃。
• 资源浪费：无谓地占用用户设备的内存，尤其是在移动设备上更为明显。

对于 React 应用而言，组件的频繁挂载、卸载、更新，以及与外部系统（如事件监听器、定时器、WebSocket 等）的交互，都为内存泄漏提供了温床。

1.2 React 应用中常见的内存泄漏源

• 未清理的事件监听器：在组件挂载时添加，但在卸载时忘记移除。
• 未清理的定时器：setInterval 或 setTimeout 在组件卸载后仍在运行。
• 全局或长寿命缓存：将组件实例、DOM 节点或组件内部状态的引用存储在全局变量或不易被垃圾回收的缓存中。
• 闭包捕获：函数（闭包）捕获了组件内部的变量，而这个闭包被传递给了一个长寿命的对象，从而阻止了组件相关资源的垃圾回收。
• DOM 节点泄漏：组件卸载后，其渲染的 DOM 节点由于某种原因（如事件监听器、第三方库的引用）未被浏览器回收。

在这些泄漏源中，闭包捕获 Fiber 节点是特别复杂的一种，因为它涉及到 JavaScript 运行时的底层机制以及 React 的内部实现。

1.3 什么是内存快照？

内存快照（Heap Snapshot）是浏览器在某个特定时间点对 JavaScript 堆内存中所有对象及其相互引用关系的一次完整记录。通过分析内存快照，我们可以：

• 识别未被垃圾回收的对象：找出那些本应被回收但仍存在于内存中的对象。
• 理解对象之间的引用关系：通过“保留器”（Retainers）视图，查看哪些对象持有对目标对象的引用，从而阻止其被垃圾回收。
• 比较不同时间点的内存状态：通过对比两个快照，精准定位在特定操作后新增的、未被回收的对象。

这正是我们解析被闭包扣留的 Fiber 节点的强大工具。

---

第二章：React Fiber 架构概览

在深入内存快照之前，理解 React Fiber 架构是至关重要的。Fiber 是 React 16 引入的全新协调（reconciliation）引擎，它重写了 React 的核心算法，以实现并发模式（Concurrent Mode）、可中断渲染、优先级调度等高级特性。

2.1 Fiber 是什么？

简单来说，Fiber 是 React 内部工作单元的抽象。每个 Fiber 节点代表一个 React 元素（Component、DOM 元素等）在工作树中的一个实例。它是一个纯 JavaScript 对象，存储了关于该组件或元素类型、状态、属性、子节点、父节点等所有必要的信息。

2.2 Fiber 节点的核心属性

一个 Fiber 节点包含大量内部属性，其中一些在内存分析中尤其重要：

属性名称	类型	描述
tag	number	标识 Fiber 节点的类型，例如：FunctionComponent (0), ClassComponent (1), HostRoot (3, 根节点), HostComponent (5, DOM 元素), Fragment (7) 等。这是我们识别 Fiber 节点类型的重要线索。
type	any	对于函数组件，是函数本身；对于类组件，是类构造函数；对于 DOM 元素，是字符串（如 'div', 'span'）。这可以帮助我们关联到具体的组件代码。
stateNode	any	对于 HostComponent (DOM 元素)，stateNode 指向实际的 DOM 节点；对于类组件，stateNode 指向组件实例。这是连接 Fiber 内部表示与外部实际对象的关键。
return	Fiber	指向父级 Fiber 节点。
child	Fiber	指向第一个子 Fiber 节点。
sibling	Fiber	指向下一个兄弟 Fiber 节点。
memoizedProps	object	上一次渲染或协调完成后，该 Fiber 节点使用的 props。
pendingProps	object	新传入的、尚未处理的 props。
memoizedState	any	上一次渲染或协调完成后，该 Fiber 节点的状态。对于函数组件，它是一个链表结构，存储了 useState, useEffect, useRef 等 Hook 的状态和副作用信息。这是闭包最常捕获的内部数据之一。
updateQueue	object	存储了待处理的状态更新（setState）或 Hook 更新。
dependencies	object	对于 Hooks，特别是 useContext，这里会存储其依赖项，用于优化更新。
flags	number	描述该 Fiber 节点需要执行哪些副作用（如 DOM 插入、更新、删除）。
expirationTime	number	表示该 Fiber 节点的优先级。

2.3 Fiber 树与工作机制

React 维护两棵 Fiber 树：

1. Current 树：代表当前屏幕上渲染的 UI 状态。
2. WorkInProgress 树：正在构建的、用于下一次渲染的 UI 状态。

当状态更新发生时，React 会从 Current 树的根节点开始，遍历并构建 WorkInProgress 树。每个 Fiber 节点在处理过程中，都会经历“工作循环”，包括执行组件函数（对于函数组件）、计算差异、应用副作用等。当 WorkInProgress 树构建完毕并通过“提交阶段”（Commit Phase）后，它会成为新的 Current 树，并更新到实际的 DOM。

一个组件被卸载时，其对应的 Fiber 节点及其子树将从 Current 树中移除，并期望被垃圾回收。如果它们没有被回收，那么就可能存在内存泄漏。

---

第三章：闭包如何扣留 Fiber 节点

闭包是 JavaScript 中一个强大而常见的特性：一个函数可以记住并访问其“词法作用域”（lexical scope），即使该函数在其词法作用域之外被执行。这个特性是双刃剑，它在提供灵活性的同时，也可能导致内存泄漏。

3.1 闭包捕获的机制

当一个内部函数引用了其外部函数作用域中的变量时，即使外部函数执行完毕，这些被引用的变量也不会被垃圾回收，因为内部函数（闭包）仍然需要它们。

function outerFunction() {
  let largeData = new Array(10000).fill('some data'); // 大量数据
  let componentState = { /* ... */ }; // 假设这是某个组件的内部状态

  function innerFunction() {
    console.log(largeData.length);
    console.log(componentState); // innerFunction 捕获了 largeData 和 componentState
  }

  return innerFunction;
}

let persistentRef = outerFunction(); // innerFunction 被返回并赋值给 persistentRef
// 此时 outerFunction 已经执行完毕，但 largeData 和 componentState 不会被回收，
// 因为 persistentRef (innerFunction) 仍然引用着它们。

3.2 闭包与 React Fiber 的泄漏场景

在 React 中，闭包可以间接或直接地捕获 Fiber 节点或其内部状态：

1. useEffect 中未清理的副作用函数：
   useEffect 是执行副作用的 Hook。如果 useEffect 中的回调函数创建了一个闭包，而这个闭包又被传递给了一个长寿命的外部对象（如全局变量、事件管理器），并且在组件卸载时没有被清理，那么这个闭包就会持续持有它所捕获的组件内部变量（包括 props, state, refs 等），这些变量可能间接引用了 Fiber 节点或其 memoizedState。

   // LeakyComponent.js - 泄漏示例
   import React, { useEffect, useState } from 'react';
   
   // 假设这是一个全局的事件订阅器或缓存
   const globalLeakyStore = {};
   
   const LeakyComponent = ({ id }) => {
     const [count, setCount] = useState(0); // 内部状态
   
     useEffect(() => {
       // 这个函数是一个闭包，它捕获了当前的 `count` 状态
       // 它还间接捕获了组件的整个词法环境，包括对 Fiber 节点相关信息的引用
       const updateCountGlobally = () => {
         console.log(`Component ${id} current count: ${count}`);
         // 在实际场景中，这个函数可能还会操作一些组件内部的 DOM 元素
         // 导致 DOM 元素和其关联的 Fiber 节点无法被回收
       };
   
       // 将闭包存储到全局变量中，且没有在 cleanup 中移除
       globalLeakyStore[id] = updateCountGlobally;
   
       // 定时器也可能导致类似问题，但此处我们更关注闭包本身
       const timerId = setInterval(() => {
         setCount(c => c + 1);
       }, 1000);
   
       return () => {
         // ⚠️ 缺少对 globalLeakyStore[id] 的清理
         clearInterval(timerId);
         console.log(`Component ${id} cleanup`);
         // 正确的清理应该包含：delete globalLeakyStore[id];
       };
     }, [id, count]); // 依赖 count 意味着每次 count 变化都会重新创建这个 effect
   
     return (
       <div>
         <p>Leaky Component {id}: Count {count}</p>
       </div>
     );
   };
   
   export default LeakyComponent;

   在这个例子中，updateCountGlobally 是一个闭包，它捕获了 count。当 LeakyComponent 卸载时，如果 globalLeakyStore[id] 没有被清除，那么这个闭包仍然存在，阻止了 count 状态及其关联的 React 内部状态（如 Fiber 节点的 memoizedState）被垃圾回收。

2. 事件监听器中的闭包：
   如果组件内部的事件监听器函数（也是闭包）被直接附加到全局对象、window、document 或一个在组件生命周期之外存在的 DOM 元素上，并且在组件卸载时没有被移除，这些闭包就会持续引用组件内部的数据。

3. 第三方库或 SDK 的回调：
   一些第三方库或 SDK 可能要求你注册回调函数。如果这些回调函数是闭包，捕获了组件内部状态，并且库本身没有提供或你忘记调用注销方法，同样会造成泄漏。

4. Promise 或异步操作链：
   如果一个 Promise 的回调函数捕获了组件内部状态，而 Promise 链在组件卸载后仍然悬而未决，那么直到 Promise 解决或拒绝，这个闭包都可能阻止相关内存的回收。

---

第四章：实践：捕获与初步分析内存快照

现在，我们准备动手操作，捕获并分析内存快照。

4.1 准备工作

1. 识别潜在泄漏点：
   基于上述泄漏场景，思考应用中哪些部分可能存在问题。通常涉及：

   • 生命周期复杂的组件。
   • 与外部系统交互（如订阅、WebSocket、第三方 SDK）的组件。
   • 使用 setInterval/setTimeout 的组件。
   • 大量使用 useEffect 且依赖项不明确的组件。
   • 频繁挂载和卸载的组件。

2. 构建测试用例：
   为了模拟泄漏，我们需要一个能够重复挂载和卸载组件的场景。以上面的 LeakyComponent 为例：

   // App.js
   import React, { useState } from 'react';
   import LeakyComponent from './LeakyComponent'; // 导入泄漏组件
   
   function App() {
     const [showComponentA, setShowComponentA] = useState(true);
     const [showComponentB, setShowComponentB] = useState(false);
   
     const toggleComponents = () => {
       if (showComponentA) {
         setShowComponentA(false);
         setShowComponentB(true);
       } else if (showComponentB) {
         setShowComponentB(false);
         setShowComponentA(true);
       } else {
         setShowComponentA(true); // Initial state
       }
     };
   
     return (
       <div>
         <h1>Memory Leak Demo</h1>
         <button onClick={toggleComponents}>Toggle Leaky Components</button>
         {showComponentA && <LeakyComponent id="A" />}
         {showComponentB && <LeakyComponent id="B" />}
       </div>
     );
   }
   
   export default App;

   这个 App 组件允许我们通过点击按钮来交替挂载和卸载 LeakyComponent，从而触发泄漏。

4.2 捕获内存快照的策略

我们采用“三次快照法”来精确识别泄漏：

1. 快照 1 (Baseline)：在应用加载完成、没有进行任何可疑操作时拍摄，作为基准。
2. 快照 2 (Action)：执行一次或多次可能导致泄漏的操作（例如，挂载并卸载 LeakyComponent）。
3. 快照 3 (Repeat Action)：再次执行相同操作，确保泄漏是持续发生的，而不是单次操作的偶然现象。

步骤：

1. 打开 DevTools：在 Chrome 浏览器中，右键点击页面 -> 检查，然后导航到 Memory 选项卡。
2. 选择 Heap snapshot：确保已选择 Heap snapshot 选项。
3. 拍摄快照 1 (Baseline)：
   • 刷新页面，确保应用处于初始状态。
   • 点击 Take snapshot 按钮。等待快照生成。
4. 执行操作：
   • 在我们的 App 示例中，点击 Toggle Leaky Components 按钮，先展示 LeakyComponent id="A"，然后再次点击，展示 LeakyComponent id="B"。此时 LeakyComponent id="A" 已经被卸载。
5. 强制垃圾回收：
   • 在 Memory 选项卡中，点击垃圾桶图标（Collect garbage）强制执行一次垃圾回收。这确保了所有可回收的对象都被清除，只留下泄漏的对象。
6. 拍摄快照 2 (Action)：
   • 再次点击 Take snapshot。等待快照生成。
7. 执行重复操作：
   • 再次点击 Toggle Leaky Components 按钮，展示 LeakyComponent id="A"，然后再次点击，展示 LeakyComponent id="B"。此时 LeakyComponent id="B" 已经被卸载。
8. 强制垃圾回收：
   • 再次点击垃圾桶图标。
9. 拍摄快照 3 (Repeat Action)：
   • 再次点击 Take snapshot。等待快照生成。

4.3 初步分析与比较

现在我们有了三个快照，最重要的是对比它们。

1. 选择比较模式：

   • 在快照 3 的顶部下拉菜单中，选择 Comparison，并选择与 Snapshot 2 进行比较。
   • DevTools 会显示自 Snapshot 2 以来新增的对象（+ 前缀）、被删除的对象（- 前缀）以及未变化的对象。
   • 我们也可以选择与 Snapshot 1 比较，但比较相邻的快照更能体现单次操作后的变化。

2. 关注 (diff) 列：

   • #Delta：表示对象数量的变化。寻找那些数量增加的对象，尤其是那些本应被回收但数量却持续增加的对象。
   • Size Delta：表示内存大小的变化。

3. 初步筛选：

   • 在 Class filter 框中输入关键字进行筛选。
     • Fiber：直接搜索 Fiber 节点。React Fiber 节点在快照中通常以 FiberNode 或具有 tag、memoizedState 等特征的对象形式出现。
     • 组件名称：例如 LeakyComponent。虽然 Fiber 节点不直接以组件命名，但组件的闭包可能会捕获与其相关的对象。
     • detached：搜索“分离的 DOM 节点”。如果一个组件的 DOM 节点被卸载了但仍存在于内存中，它会显示为 detached。这通常是 Fiber 泄漏的伴随症状。
     • Object / Function：这些是更通用的类型，但闭包本身就是 Function 对象。

   通过比较 Snapshot 2 和 Snapshot 3，我们会发现 LeakyComponent id="A" 和 id="B" 对应的 Fiber 节点数量持续增加，或者其关联的对象数量持续增加，但并未被回收。

   例如，如果我们搜索 Fiber，可能会看到 FiberNode 类型的对象在每次卸载后都有新增，并且其 Distance (到根节点的距离) 较大，意味着它们不是被强引用在某个简单对象中，而是通过复杂的引用链被保留。

---

第五章：深入解析：定位被闭包扣留的 Fiber 节点

现在我们进入核心环节：如何从茫茫对象中找到那些被闭包扣留的 Fiber 节点，并理解其保留路径。

5.1 识别 Fiber 节点

在 Heap snapshot 的 Summary 视图中，通过 Class filter 搜索 Fiber 或 FiberNode。

• 特征：
  • 对象名可能是 FiberNode 或类似。
  • 它们会有明显的 tag (数字，如 0, 1, 5 等)。
  • type 属性会指向组件函数或类。
  • stateNode 属性会指向对应的 DOM 元素（如果它是一个 HostComponent）或组件实例（如果它是一个 ClassComponent）。
  • memoizedState 属性会存储 Hook 的状态。

在我们的泄漏示例中，当 LeakyComponent 被卸载后，我们期望其对应的 Fiber 节点被垃圾回收。如果它们没有被回收，在比较快照时，它们将显示为“新增”的对象，其数量会随着每次挂载/卸载操作而增加。

5.2 追踪保留器路径 (Retainers)

这是最关键的一步。选中一个可疑的 FiberNode 对象，在下方的 Retainers 区域，DevTools 会显示一个树状结构，揭示了从全局根（window）到该对象的引用链。

示例分析步骤 (基于 LeakyComponent 泄漏)：

1. 找到泄漏的 Fiber 节点：

   • 在 Snapshot 3 中，选择与 Snapshot 2 比较。
   • 在 Class filter 中输入 Fiber。
   • 你会看到一些 FiberNode 类型的对象，其 #Delta 可能是 +1 或 +2，表示有新的 Fiber 节点被创建但未被回收。
   • 点击其中一个 FiberNode，它通常会有一个 tag 属性（例如 0 代表函数组件），并且 type 属性会显示 LeakyComponent。
   • 观察其 Distance，如果它不是 1 或 2，说明不是直接被全局变量引用，而是通过更长的链条。

2. 分析 Retainers 视图：

   • 选中这个泄漏的 FiberNode。
   • 在 Retainers 窗格中，你会看到一个引用链，例如：

     (global property) window
       -> globalLeakyStore
         -> (key: "A")
           -> updateCountGlobally (Function)
             -> (closure)
               -> count (number) // 捕获了 count 变量
               -> (context) // 闭包的上下文，包含了组件的整个作用域
                 -> LeakyComponent (Function)
                   -> (context)
                     -> (Hook) // 这里的 Hook 结构会引用到 Fiber 节点
                       -> memoizedState (object)
                         -> LeakyComponent (FiberNode) // 找到了！

   • 解释路径：
     • global property window: 引用链的起点，通常是全局对象。
     • globalLeakyStore: 全局变量，我们的泄漏源。
     • (key: "A"): globalLeakyStore 中以 "A" 为键存储的对象。
     • updateCountGlobally (Function): 这是我们的闭包函数。这是关键！
     • (closure): 表示这是一个闭包，它有自己的作用域。
     • count (number): 闭包捕获的 count 变量。
     • (context): 这是一个非常重要的节点，它代表了闭包被创建时的词法环境。在这个环境中，我们可以找到组件相关的变量。
     • LeakyComponent (Function): 在这个上下文中，会找到组件的函数定义。
     • (context) -> (Hook) -> memoizedState: 最终你会发现这个链条会指向一个包含 memoizedState 的对象，这个 memoizedState 最终会引用到我们的 FiberNode。

   这个路径清楚地表明：window 持有 globalLeakyStore，globalLeakyStore 持有 updateCountGlobally 这个闭包函数，而这个闭包函数又捕获了 LeakyComponent 的词法作用域，从而间接阻止了 LeakyComponent 对应的 FiberNode 及其 memoizedState 被垃圾回收。

5.3 闭包与 memoizedState 的关联

对于函数组件，useState、useEffect、useRef 等 Hook 的状态都存储在 Fiber 节点的 memoizedState 属性中，它通常是一个链表结构。

当一个闭包捕获了组件内部的变量（如 count state），它实际上捕获了对这个变量在 memoizedState 中存储位置的引用。因此，只要闭包存在，它就会阻止 memoizedState（以及包含它的整个 Fiber 节点）被垃圾回收。

5.4 DOM 节点泄漏的辅助判断

有时，FiberNode 泄漏会伴随着 detached DOM 节点的泄漏。

• 在 Class filter 中搜索 Detached HTMLElement。
• 如果发现有数量增加的 detached div、span 等，选中它们。
• 在 Retainers 视图中，你会看到这些 DOM 节点被引用。如果引用链中出现了 FiberNode 或与组件相关的闭包，那么这进一步证实了泄漏。通常，stateNode 属性会将 FiberNode 与实际的 DOM 节点连接起来。

---

第六章：修复策略与最佳实践

一旦定位到泄漏源，修复通常是直接且明确的。核心原则是：在组件卸载时，释放所有外部引用。

6.1 useEffect 的清理函数

这是解决大部分 React 内存泄漏问题的首选机制。useEffect 的回调函数可以返回一个清理函数，这个函数会在下一次 useEffect 执行前或组件卸载时调用。

修复 LeakyComponent 示例：

import React, { useEffect, useState } from 'react';

const globalLeakyStore = {}; // 假设的全局存储

const LeakyComponent = ({ id }) => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const updateCountGlobally = () => {
      console.log(`Component ${id} current count: ${count}`);
    };

    globalLeakyStore[id] = updateCountGlobally; // 存储闭包

    const timerId = setInterval(() => {
      setCount(c => c + 1);
    }, 1000);

    return () => {
      // ✅ 关键修复：在组件卸载时，从全局存储中移除引用
      delete globalLeakyStore[id];
      clearInterval(timerId);
      console.log(`Component ${id} cleanup`);
    };
  }, [id, count]); // 依赖 count 意味着每次 count 变化都会重新创建这个 effect

  return (
    <div>
      <p>Leaky Component {id}: Count {count}</p>
    </div>
  );
};

export default LeakyComponent;

通过在 useEffect 的清理函数中添加 delete globalLeakyStore[id];，我们确保当组件卸载时，不再有外部引用指向 updateCountGlobally 这个闭包。一旦没有其他引用，闭包及其捕获的 count 变量和关联的 Fiber 节点就能够被垃圾回收。

6.2 移除事件监听器

如果事件监听器是导致泄漏的原因，务必在清理函数中移除它们。

useEffect(() => {
  const handleScroll = () => { /* ... */ };
  window.addEventListener('scroll', handleScroll);
  return () => {
    window.removeEventListener('scroll', handleScroll); // 移除监听器
  };
}, []);

6.3 清除定时器

所有 setInterval 和 setTimeout 都必须在清理函数中通过 clearInterval 或 clearTimeout 清除。

useEffect(() => {
  const timer = setInterval(() => { /* ... */ }, 1000);
  return () => {
    clearInterval(timer); // 清除定时器
  };
}, []);

6.4 订阅与取消订阅

对于任何形式的订阅（如 RxJS Observables, Redux store 订阅），都要确保在清理函数中执行取消订阅操作。

useEffect(() => {
  const subscription = someService.subscribe(() => { /* ... */ });
  return () => {
    subscription.unsubscribe(); // 取消订阅
  };
}, []);

6.5 谨慎使用全局状态与缓存

• 如果必须使用全局状态或缓存，确保提供明确的清理机制，以便在组件不再需要时移除其数据或回调。
• 考虑使用 WeakMap 或 WeakSet。如果你的缓存只需要持有对对象的“弱引用”，即不阻止对象被垃圾回收，那么 WeakMap 或 WeakSet 是一个不错的选择。它们只允许对象作为键，并且一旦键对象没有其他强引用，就会被自动垃圾回收，并从 WeakMap/WeakSet 中移除。但它们不能被迭代，也不能获取所有键。

6.6 useCallback 和 useMemo 的作用

虽然主要用于性能优化，但它们间接有助于防止不必要的闭包创建。如果一个回调函数或对象在每次渲染时都被重新创建，那么它每次都会捕获新的词法环境。通过 useCallback 和 useMemo，可以在依赖项不变的情况下复用同一个函数或对象，从而避免创建新的、可能带有泄漏风险的闭包。

// 使用 useCallback 避免不必要的函数重新创建
const handleClick = useCallback(() => {
  // 这个闭包只会在 count 变化时重新创建
  console.log('Count:', count);
}, [count]);

但这并不能直接解决闭包被外部长寿命对象引用的问题，它只是减少了闭包的“更新频率”。

---

第七章：高级考虑与调试技巧

7.1 React DevTools 与内存快照的结合

React DevTools 是一个强大的浏览器扩展，可以帮助我们检查 React 组件树、props 和 state。在调试内存泄漏时，它可以作为内存快照的有力补充：

1. 识别组件实例：使用 React DevTools 找到你怀疑泄漏的组件实例。
2. 定位 DOM 节点：在 React DevTools 中选中组件后，点击右侧的“Go to source”或“Inspect DOM element”，可以直接跳转到 Chrome DevTools 的 Elements 选项卡，定位到该组件渲染的实际 DOM 节点。
3. 在内存快照中搜索 DOM 节点：复制该 DOM 节点的唯一 ID (如果有) 或其他标识符。然后在 Memory 选项卡中，搜索该 DOM 节点。
4. 从 DOM 节点追溯到 Fiber：在较新版本的 React 中，DOM 节点通常不再直接持有 _reactInternalFiber 或 __reactFiber$ 这样的内部属性。但你可以从 DOM 节点的保留器链向上追溯，很可能会找到其父级 FiberNode，因为 DOM 节点是 Fiber 节点 stateNode 属性的值。

7.2 理解 [[Scopes]]

在 Retainers 视图中，当你选中一个 Function 对象（即一个闭包）时，展开它的属性，你会看到一个 [[Scopes]] 属性。这个属性包含了闭包捕获的所有作用域链：

• Closure：包含了闭包内部定义的变量以及它从外部作用域捕获的变量。
• Script：全局作用域。
• Global：通常是 window 对象。

检查 Closure 作用域中的变量，你会发现那些被闭包捕获的组件内部状态、props 或其他引用。这直接证实了闭包的存在以及它所捕获的内容，从而帮助你理解为什么 Fiber 节点会被保留。

7.3 持续监控

内存泄漏的检测不应是一次性的任务。在应用的开发和维护过程中，应定期进行性能和内存分析。集成自动化测试，例如基于 Puppeteer 的内存回归测试，可以在每次代码提交时检测新的内存泄漏。

---

终章：理解与实践的融合

解析 ‘Heap Snapshots’ 中的 React 节点，特别是查找被闭包扣留的 Fiber 节点，是一项需要深入理解 JavaScript 运行时、React 内部机制和浏览器调试工具的综合技能。通过系统地学习 Fiber 架构、掌握内存快照的捕获与分析策略，并结合具体的代码示例和详细的保留器路径追踪，我们可以有效地识别并修复这些隐蔽的内存泄漏问题。这不仅能显著提升应用的性能和稳定性，更能加深我们对前端工程化和内存管理精髓的理解。