各位好，欢迎来到今天的“React 内存大扫除”研讨会。
说实话，提到内存泄漏，大多数前端开发者的第一反应大概就是：“哦，那个东西吧？反正服务器重启一下就好了。”
别天真了，朋友。在千万级流量的应用里，内存泄漏不是“感冒”，它是“癌症”。它不声不响，不痛不痒，就像你那个总是半夜偷吃冰箱里蛋糕的室友，等你发现的时候，冰箱已经塞满了，甚至发霉了。
今天我们不谈虚的，咱们就来聊聊怎么用 Chrome DevTools 这把手术刀，把藏在 Fiber 节点里的那些“幽灵”给揪出来。特别是那些导致静默溢出的罪魁祸首。
咱们先来聊聊 React 的 Fiber 架构。很多人觉得 Fiber 就是一棵树，一棵虚拟的 DOM 树。错！大错特错。
Fiber 其实是一个链表结构。它是 React 的调度核心，是一个个独立的“工作单元”。每一个组件都是一个 Fiber 节点。如果一个组件没有被卸载，那么对应的 Fiber 节点就永远存在于内存中。如果这个组件被渲染了一万次，虽然可能复用，但如果组件本身极其复杂，或者它的 props、state 包含了巨大的对象，那么这些数据就会像脂肪一样堆积在内存里。
当千万级流量涌入，页面频繁的挂载和卸载会产生海量的 Fiber 节点。如果这些节点没有被正确地“断开连接”，它们就会形成一条长长的、吞噬内存的贪吃蛇。这条蛇在后台静静地游走，直到你的服务器内存爆满，或者用户手机发烫。
那么，我们怎么抓这条蛇呢？
首先，你得有工具。Chrome DevTools 是你的显微镜。
第一步：快照——拍一张“尸检照片”
很多人用 Chrome 的 Memory 面板，就像在菜市场买菜，随便拍一张照，看看“Total size”，然后说：“哎呀，好多内存，有点大。”然后就走了。
这就像是你去体检，医生问你哪里不舒服，你只说：“我感觉我有点重。”这是没有用的。
在千万级流量的应用中，内存的使用是动态的。你不能只看一个静态的快照。你需要的是对比。
操作指南：
- 打开 Chrome DevTools，切换到 Memory 面板。
- 选择“Heap snapshot”。
- 关键点来了： 在左上角的 Filter 里，不要选
all。选Summary。 - 点击左上角的那个像照相机一样的图标，拍下第一张快照。我们叫它“基准快照”。
然后，你需要去触发你的业务逻辑。比如，去一个有内存泄漏嫌疑的页面，疯狂点击按钮，或者频繁切换 Tab，让组件疯狂挂载。操作一段时间后，再次点击照相机图标，拍下第二张快照。
核心技巧：
在两张快照之间，点击“Compare with previous snapshot”（与上一张快照比较）。
这时候，你会看到一列数据。别慌，这里面全是宝藏。
你会看到一个 # of New instances（新实例数量）列。如果这个数字一直在涨，哪怕涨幅不大，那也是警报。你还要看 Delta（增量）。如果 Delta 是正数，说明内存正在增长。
这时候，你可能会看到一个组件，比如 MyHugeComponent，它的实例数量在不断增加。
第二步：堆栈分析——解剖 Fiber 节点
光看到组件名还不够。你还得知道这个组件为什么没死。
选中那个 MyHugeComponent，在右侧的详情面板里，你会看到它的原型链。这里就是 Fiber 节点的解剖室。
1. 查看构造函数
看看 # of Constructor calls。如果这个数字在涨，说明每次渲染都在重新创建这个组件的实例。这通常意味着你的组件在 render 函数里创建了新的对象，或者你使用了高阶组件（HOC）没有做缓存。
2. 查看挂载与更新
这是堆栈分析最精彩的地方。在快照的底部，有一个 Constructor，Mount，Update 的分类。
- Constructor: 组件被创建的时候。
- Mount: 组件第一次被挂载到 DOM 的时候。
- Update: 组件更新的时候。
如果你发现 Constructor 的数量在疯狂增加，那说明你的组件实例根本没有被卸载。React 的生命周期里，unmount 的时候会销毁实例。如果实例没销毁，那就是泄漏。
第三步：代码实战——抓住那只“偷油的老鼠”
光说不练假把式。咱们来看几个典型的 Fiber 节点泄漏场景，以及它们在堆栈分析里长什么样。
场景一：忘记清理的定时器
这是最经典的“新手错误”。
function TimerComponent() {
useEffect(() => {
const id = setInterval(() => {
console.log("Tick");
}, 1000);
// 忘记写 return () => clearInterval(id);
// 或者 return 写错位置了
}, []);
return <div>Timer Running</div>;
}诊断过程：
当你拍完快照，你会发现 TimerComponent 的实例数量在不断增加。
点击进入详情，你会发现它的 # of Constructor calls 在增加。
在 Constructor 的堆栈里，你会看到你的 render 函数。
更关键的是，在 Constructor 的堆栈深处，你会看到 setInterval 的调用。因为 setInterval 返回的 ID 被保存在了组件的闭包里，而这个闭包随着组件实例的存在而存在。Fiber 节点持有这个闭包，闭包持有 ID，ID 持有定时器，定时器持有回调，回调持有组件实例……这是一个完美的死循环。
场景二：闭包陷阱——吃不下吐不出的胖子
这是千万级流量应用中最隐蔽的杀手。
function BigDataComponent() {
const [data, setData] = useState([]);
useEffect(() => {
// 模拟获取大量数据
const fetchData = async () => {
const hugeData = await fetchHugeDataset(); // 假设这个数据有 50MB
setData(hugeData);
};
fetchData();
}, []);
const handleClick = () => {
// 问题在这里：handleClick 闭包捕获了 hugeData
console.log(hugeData.length); // 报错！hugeData 没定义
};
return <button onClick={handleClick}>Click Me</button>;
}等等，上面的代码是错的。 正确的代码应该是这样才对：
function BigDataComponent() {
const [data, setData] = useState([]);
useEffect(() => {
const fetchData = async () => {
const hugeData = await fetchHugeDataset();
setData(hugeData);
};
fetchData();
}, []);
const handleClick = () => {
// 修正：使用 data
console.log(data.length);
};
return <button onClick={handleClick}>Click Me</button>;
}看起来没问题对吧？但是，如果在千万级流量的场景下，你的 handleClick 被频繁传递给了子组件，或者被用作 ref.current。
诊断过程：
当你拍快照，你会发现 BigDataComponent 的实例虽然数量没变，但是 props 非常巨大。
为什么？因为 handleClick 这个函数，每次组件渲染都会重新创建。而且，如果 handleClick 里面访问了 data，那么它就闭包了 data。
在 React Fiber 的世界里，FiberNode 的 memoizedState 存储着 Hooks 的值。如果 handleClick 这个函数被存储在 DOM 节点的 stateNode（也就是真实的 DOM 元素上，作为 onclick），那么这个巨大的 data 数组就会被死死地绑在这个 DOM 节点上。
即使你把组件卸载了，只要那个 DOM 节点还在（比如你用了 useRef 或者是 position: fixed 的全屏遮罩），这个巨大的数组就永远不会被回收。
在堆栈分析里，你会看到 BigDataComponent 的 props 里有一个巨大的对象。点进去看它的 __proto__，你会发现它引用了那个巨大的数组。这就是静默溢出的根源。
场景三：全局变量污染——最坏的习惯
// 在某个全局文件里
window.globalState = {
hugeArray: new Array(1000000).fill('data')
};
function BadComponent() {
useEffect(() => {
// 没事就往全局状态里加东西
window.globalState.list.push('new item');
}, []);
return <div>Bad Component</div>;
}诊断过程：
这个最简单。在快照里搜索 globalState。你会发现无论你怎么卸载 BadComponent，window.globalState 都在那儿，而且里面的 list 越来越长。
在堆栈分析里，你会看到 window 对象持有对 globalState 的引用，globalState 持有 hugeArray 的引用。这就像是你把垃圾扔到了邻居家的后院，邻居把后院锁死了，垃圾永远出不去。
第四步：千万级流量下的特殊挑战
在千万级流量下，GC（垃圾回收）的机制会变得非常敏感。
Chrome 的 V8 引擎使用的是“标记-清除”算法。当内存不足时，它会暂停主线程，去扫描内存，标记“活着的”对象，然后清除“死去的”对象。
如果你的应用里有大量的 Fiber 节点没有释放，GC 扫描的时间就会变长。这会导致主线程暂停，也就是我们常说的“掉帧”。
想象一下，一秒钟内有一万个用户点击了你的页面，如果每个页面都泄漏了一个 1MB 的 Fiber 节点，你的 GC 就得在一秒钟内扫描 10GB 的内存。
怎么定位这种“GC 压力”导致的卡顿？
你可以使用 Chrome 的 Flame Graph（火焰图）。
- 在 Performance 面板录制一段包含卡顿的视频。
- 查看 Memory 面板。
- 点击 Take Heap Snapshot。
- 在快照列表里，点击 GC 按钮（垃圾桶图标）。
这时候，你会看到内存瞬间下降。但是，如果内存下降的速度很慢，或者下降后又迅速回升，那就说明内存泄漏非常严重。
在 Flame Graph 里，你会看到大量的 React、ReactCompositeComponent 的调用栈。如果你在录制时点击了“Take Heap Snapshot”，然后看 GC 的耗时，你会发现 GC 的耗时占据了很大比例。这说明你的应用正在被自己的内存拖垮。
第五步：工具链的最佳实践
为了在千万级流量下有效管理内存，光靠人工拍快照是不够的，我们需要建立一套标准化的工具链。
1. 自动化快照测试
在 CI/CD 流程中，增加一个测试环节。
- 启动应用。
- 模拟用户操作（比如点击按钮 100 次）。
- 拍摄快照。
- 断言：如果
MyComponent的实例数量超过了阈值（比如 50），则测试失败。
这就像是在家里装了烟雾报警器，平时不响，真着火了才知道。
2. 脏检查
不要每次渲染都拍快照，太慢了。你可以设置一个“脏检查”机制。比如每隔 5 分钟，或者每隔 100 次渲染，拍一次快照。
3. 关注 __proto__ 树
这是堆栈分析的核心。不要只看顶层对象。Fiber 节点的泄漏往往藏在深层。
- 看看
props里有没有巨大的对象。 - 看看
state里有没有巨大的数组。 - 看看有没有循环引用。
深入 Fiber 节点内部
为了更精准地定位，我们需要了解 Fiber 节点的结构。在 Chrome 的快照中，你可以展开 MyComponent，看到它的 __proto__。
// 概念结构
FiberNode {
stateNode: HTMLElement | ComponentInstance, // DOM 节点或组件实例
memoizedState: any, // Hooks 的 state
updateQueue: UpdateQueue,
// ... 其他属性
}如何通过 stateNode 定位？
如果你的组件是一个函数组件，stateNode 可能是 null（React 18 之后）。但是，如果你在代码里做了类似 ref.current = element 的操作，那么这个引用会保存在 stateNode 里。
如果这个 element 是一个巨大的 DOM 节点，或者它内部引用了巨大的数据，那它就是泄漏点。
如何通过 memoizedState 定位？
Hooks 的值存在这里。如果你使用了 useRef，并且把大对象赋值给了 ref.current，那么这个大对象会被挂在 memoizedState 的某个层级上。
代码重构——从源头断奶
找到了问题，就要解决。在千万级流量应用中，代码重构是必须的。
1. 拆分组件
如果一个组件太大了，它包含的数据也太大。把它拆成两个。小的组件更容易被 GC 回收。
2. 使用 useMemo 和 useCallback 要谨慎
很多人滥用这两个 Hook，以为能优化性能，结果反而增加了内存压力。
useCallback 会缓存函数。如果这个函数被用在大量的子组件里，或者被 useEffect 的依赖项捕获，它就会导致父组件及其所有子组件无法被卸载。
3. 避免在 render 中创建对象
// 坏代码
function MyComponent() {
return <ChildComponent config={{ id: 1, hugeData: hugeData }} />;
}
// 好代码
function MyComponent() {
const config = useMemo(() => ({ id: 1 }), []); // 缓存配置
return <ChildComponent config={config} />;
}一个具体的案例复盘
假设我们有一个电商首页，在双十一那天崩了。
现象：
- 用户打开首页，浏览 5 分钟后，页面开始卡顿。
- 手机发热严重。
- Chrome Performance 面板显示 GC 时间占比 60%。
诊断：
- 拍摄快照。发现
ProductCard组件实例数量巨大。 - 进入
ProductCard详情。发现props中的productInfo对象非常大。 - 点击
productInfo。发现它引用了一个imageList数组。 - 查看
__proto__，发现imageList里有 100 张高清大图的 Base64 字符串。
原因：
ProductCard 组件接收了包含所有图片数据的 productInfo。
而在父组件 Home 中，为了实现“无限滚动”或“下拉刷新”，组件并没有真正卸载，而是被复用了。但是，父组件在更新数据时，重新生成了一个巨大的 productInfo 对象，并传给了子组件。
因为 React 的 props 是不可变的（或者是浅比较），旧的 productInfo 没有被立即释放，它被挂在了旧 Fiber 节点的 memoizedProps 上。而旧的 Fiber 节点因为某种原因（比如 ref 引用、或者父组件的 state）没有被卸载。
于是，内存里堆积了成千上万个包含 100 张图片的 ProductCard。
解决：
- 修改
ProductCard，只接收必要的 ID，图片通过useEffect单独加载。 - 优化
Home组件的数据传递逻辑，避免传递不必要的数据。
总结一下工具链的使用流程
好了，咱们把刚才说的串起来，变成一个标准的“抓鬼流程”：
- 准备环境： 打开 Chrome，打开你的应用。确保你处于“生产模式”或者“模拟生产环境”。
- 操作复现： 模拟用户的高频操作（点击、滚动、切换路由）。
- 拍摄基准： 拍第一张快照，记下主要组件的数量。
- 疯狂压测： 继续操作，直到内存明显上升。
- 拍摄对比： 拍第二张快照，选择“Compare with previous”。
- 寻找嫌疑人： 找到实例数量持续增长的组件。
- 尸检（堆栈分析）：
- 看构造函数次数。
- 看挂载次数。
- 看实例的
props和state。 - 看原型链，找到那个巨大的数据源。
- 定位代码： 回到你的 IDE，找到这个组件，看看是不是有闭包陷阱、定时器没清理、或者全局变量污染。
- 修复验证： 修改代码，重新测试，直到快照里不再有异常增长。
最后的忠告
在千万级流量应用中，React Fiber 节点的内存管理是一场持久战。
不要迷信框架。React 虽然强大，但它不能替你写没有 Bug 的代码。它不能替你清理 setInterval，不能替你避免闭包陷阱，也不能替你清理全局变量。
作为开发者，你的责任是保持代码的“清洁”。就像打扫房间一样，用完的东西要归位，过期的垃圾要扔掉。
当你下次在深夜听到服务器风扇狂转的声音时，不要慌。打开 Chrome，拿起你的“解剖刀”（快照工具），去抓那个躲在 Fiber 节点里的幽灵吧。
记住，内存泄漏不是 Bug，它是你代码里藏着的那个懒惰的室友。别惯着他，把他赶出去。
好了，今天的讲座就到这里。大家去试试吧，祝你们的内存永远清清爽爽！