各位听众，大家好！
欢迎来到今天的“React 内部机制深度解剖”现场。我是你们的领航员，今天我们要聊的话题有点“重口味”，有点“硬核”，甚至有点“灰暗”——那就是当你的组件被卸载时，那些曾经风华正茂的 Hook 状态到底去哪了？
我们要探讨的主题是：React Hooks 状态的持久化：分析 Fiber 节点卸载后从内存中完全切断 Hook 链表引用的回收时机。
听起来是不是像是在讲一个悬疑故事？别担心，我会剥开 React 那层神秘的面纱，用最通俗、最幽默的方式，带你看看这些代码背后的“尸体”是如何被处理的。
第一部分：Fiber 与 Hooks 的“包办婚姻”
首先，我们要搞清楚两个核心角色的关系。在 React 的世界里，有两个大家族：Fiber 节点和 Hook 链表。
想象一下，Fiber 节点是房子，是组件在内存中的实体。它有四面墙（props）、一个屋顶（type）、还有一堆家具（children）。
而 Hook 链表，就是房子里的家具。
当你写 useState 的时候，你就是在往这个房子里搬家具。useState 返回的第一个值是家具的“主人”（状态值），第二个值是“搬运工”（更新函数）。useEffect 是房子里的“装修队”，useRef 是房子角落里的“储物柜”。
通常情况下，Fiber 节点和 Hook 链表是绑定在一起的。Fiber 节点有一个属性叫 memoizedState，它指向 Hook 链表的头部。
function MyComponent() {
const [count, setCount] = useState(0); // 搬进第一件家具
const [name] = useState('Alice'); // 搬进第二件家具
const timerRef = useRef(null); // 搬进一个储物柜
// ... 业务逻辑
return <div>Hello {name}</div>;
}在这个例子中，MyComponent 的 Fiber 节点里，memoizedState 指向一个包含 {state: 0, next: ..., queue: ...} 的对象，然后这个对象的 next 又指向 name 的状态对象。
它们俩是“夫妻”，是一根绳上的蚂蚱。你拆房子（卸载组件），就得把家具都清出去。
第二部分：卸载，一场“离婚”大戏
现在，让我们来点刺激的。假设你在代码里写了这样一段逻辑：
function App() {
const [show, setShow] = useState(true);
return (
<div>
{show && <Counter />}
<button onClick={() => setShow(false)}>卸载组件</button>
</div>
);
}
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
console.log('组件挂载了！');
return () => {
console.log('组件卸载了！清理工作开始...');
};
}, []);
return (
<div>
<p>Count: {count}</p>
<button onClick={() => setCount(c => c + 1)}>+1</button>
</div>
);
}当你点击“卸载组件”时，Counter 组件消失了。这时候，React 会做什么？
很多人直觉认为，状态还在，只是被隐藏了。错！大错特错！
React 的哲学是“声明式”的。如果你把房子拆了，房子里的家具（状态）自然也就没了。它们不会凭空消失，也不会被藏在某个魔法口袋里等待下个轮回。它们会被销毁。
这个过程在 React 源码中对应的核心函数是 unmountFiber（在 Fiber 架构下）或 unmountComponentAtNode（旧版）。
让我们进入源码的视角，看看这个“离婚”现场是怎么发生的。
第三部分：Hook 链表的“断舍离”
当 React 决定卸载一个 Fiber 节点时，它会执行一系列清理操作。最关键的一步，就是切断 Hook 链表的引用。
源码逻辑大致是这样的（伪代码简化版）：
function unmountFiber(fiber) {
// 1. 标记 Fiber 为非活跃状态
fiber.flags |= DidCapture;
// 2. 关键步骤：遍历 Hook 链表并清空
// 注意：这里是从 currentFiber.memoizedState 开始的
let hook = fiber.memoizedState;
while (hook) {
// 3. 清理副作用（Effect）
// 比如 useEffect 的清理函数，或者 useLayoutEffect
if (hook.nextEffect !== null) {
// 调用 cleanup 函数
}
// 4. 核心操作：切断引用
// hook.nextEffect = null; // 断开与下一个 Hook 的联系（虽然 unmount 时通常不需要，但保持链表断裂是好习惯）
// 5. 把 memoizedState 设为 null
// 这是最重要的一步！意味着这个 Fiber 节点不再持有任何状态数据了。
// hook.memoizedState = null;
// 注意：React 实际实现中，hook 本身可能被复用或者被置空，
// 但对于该 Fiber 节点而言，它已经和状态解绑了。
hook = hook.next;
}
// 6. Fiber 节点本身从树中移除
fiber.return = null;
fiber.dependencies = null;
fiber.memoizedState = null; // 再次确认，彻底清空
fiber.updateQueue = null;
}这里有一个非常微妙的点：memoizedState 被设为 null。
这意味着，如果此时有人试图通过某种方式访问这个 Fiber 节点的 memoizedState，他会得到 null。Hook 链表彻底断裂了。
为什么这很重要？
这直接回答了你的问题：Hook 链表引用的切断时机。
这个切断动作发生在 React 开始卸载组件的那一刻。它是不可逆的。一旦 memoizedState 变成 null，React 就认为这个组件已经“死”了，它的状态数据不再属于它。
第四部分：内存泄漏的“幽灵”与 Ref 的陷阱
虽然 React 很努力地把 Hook 链表切断了，但现实往往是残酷的。有时候，你以为你切断了，但实际上并没有。
为什么？因为 JavaScript 的垃圾回收机制（GC）虽然强大，但它不是魔法。GC 的原则是：“如果没有任何引用指向这个对象，我就把它回收。”
React 切断了 Fiber 节点对 Hook 状态的引用，但是，如果还有其他地方持有这个 Hook 状态对象的引用，那么 GC 就不会回收它。
这里有几个经典的“坑”。
场景一：useRef 的“背叛”
function Counter() {
const [count, setCount] = useState(0);
// 我们把状态存到了 ref 里
const stateRef = useRef(count);
useEffect(() => {
// 这里有个定时器，引用了 stateRef
const id = setInterval(() => {
console.log(stateRef.current); // 总是能打印出最新的 count
}, 1000);
return () => {
clearInterval(id);
};
}, []);
return <button onClick={() => setCount(c => c + 1)}>+1</button>;
}问题来了：
当你卸载 Counter 组件时，React 把 Counter Fiber 节点的 memoizedState 设为了 null。这意味着 count 的状态数据被切断了。
但是！stateRef.current 还指着那个状态数据！
虽然 Counter 组件的 UI 消失了，但在内存深处，那个状态对象依然被 stateRef 持有，依然被 setInterval 的闭包持有。
结果： 内存泄漏。Hook 链表虽然断了，但“幽灵”还赖着不走。
场景二：事件监听器的“私生子”
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const handler = () => {
console.log('Count is:', count);
};
window.addEventListener('resize', handler);
return () => {
window.removeEventListener('resize', handler);
};
}, [count]); // 依赖项包含 count
}这里，闭包 handler 捕获了 count。
当你卸载组件时，React 切断了 Hook 链表。但是，如果你忘记在 cleanup 函数里移除 resize 监听器（或者依赖项写错了），handler 依然存在，它依然引用着那个已经被切断的状态对象。
GC 就会盯着这个 handler 发呆：“我不敢动，因为有人引用了它。”
第五部分：Fiber 节点的“火葬场”
让我们把镜头拉远，看看整个卸载流程的闭环。
当 unmountFiber 完成后，Fiber 节点从 current 树（正在渲染的树）中移除了。它现在是一个“孤儿”。
此时，内存中的情况是这样的：
- Hook 链表：已经断裂，
memoizedState为null。 - Fiber 节点：依然存在于内存中（作为
alternate节点存在，或者是被 React 内部某些机制暂存）。 - 闭包与 Ref：如果存在，依然持有旧数据的引用。
GC 什么时候介入？
这就取决于 V8 引擎的调度了。通常情况下，只要没有强引用存在，垃圾回收器会在下一次 GC 周期到来时，回收这些不再被使用的 Fiber 节点、Hook 链表对象以及相关的闭包。
但是，React 为了性能，不会把刚刚卸载的 Fiber 节点立刻扔进垃圾桶。它可能会把它们保留在 FiberRootNode.current.alternate 中，以便在下次更新时复用（如果组件重新挂载）。
回收的时机总结：
- 引用切断时刻：
unmountFiber执行，memoizedState被置为null。这是逻辑上的切断。 - 组件卸载时刻：Fiber 节点从渲染树中移除。
- GC 回收时刻：当没有任何变量、闭包或 React 内部引用指向这些 Fiber 节点及其 Hook 状态时，V8 引擎将其回收。
第六部分：实战代码追踪
让我们通过一段代码，模拟一下从“活着”到“死掉”的过程。
// 模拟一个组件
function TestComponent() {
const [state, setState] = useState('I am alive');
const ref = useRef(null);
useEffect(() => {
// 记录当前状态对象的内存地址
ref.current = state;
console.log('Mounted, State Addr:', ref.current);
return () => {
console.log('Unmounting...');
console.log('State Addr still in Ref:', ref.current);
console.log('Is memoizedState null?', null); // 假设这里能直接看 Fiber
};
}, []);
return <div>{state}</div>;
}执行流程：
- Mount：
TestComponent挂载。Fiber 节点的memoizedState指向一个对象{ value: 'I am alive' }。ref.current指向这个对象。 - Unmount：组件被移除。React 调用
unmountFiber。- React 遍历 Hook 链表。
- React 执行
return () => { ... }。 - React 设置
fiber.memoizedState = null。 - 此时，
memoizedState指向null。原来的状态对象（{ value: 'I am alive' }）在 React 的视角里已经“断头”了。
- GC：如果没有其他东西引用那个状态对象，它变成垃圾。
但是！ 如果你在 return 的清理函数里写了：
return () => {
// 致命错误：把 Fiber 引用保存了下来
window.__tempFiber = fiber;
};那么，即使组件卸载了，Fiber 节点和它的 Hook 状态依然会被 window.__tempFiber 牢牢抓住。GC 永远无法回收它们。这就是典型的“人为造成的内存泄漏”。
第七部分：深入剖析 memoizedState 的链表结构
为了更深刻地理解“切断”，我们必须看看 memoizedState 到底是个什么结构。
它是一个单向链表。每个 Hook 节点大致长这样：
{
memoizedState: value, // 当前 Hook 的状态值
next: nextHook, // 指向下一个 Hook
queue: updateQueue, // 待处理的更新队列
baseState: baseState, // 基础状态
nextEffect: nextEffect // 用于副作用链表
}当你卸载组件时，React 不仅仅是把最后一个 Hook 设为 null，而是遍历整个链表。
// 伪代码
function resetFiberHooks(fiber) {
let hook = fiber.memoizedState;
while (hook) {
const nextHook = hook.next;
// 清空当前 Hook 的各种属性
hook.memoizedState = null;
hook.queue = null;
hook.next = null;
hook.nextEffect = null;
hook = nextHook;
}
fiber.memoizedState = null;
}这个过程非常彻底。它把整个 Hook 链表“掏空”了。
第八部分：为什么我们要关注这个？
有人可能会问：“这有什么关系？反正用户看不见，内存少点少点呗。”
关系大了！
- 性能优化：如果你在开发一个大型应用，频繁地挂载和卸载组件（比如在一个列表里做筛选、分页），如果 Hook 状态没有被正确切断和回收，你的内存占用会像滚雪球一样越来越大。最终，浏览器会卡顿，甚至崩溃。
- 调试：如果你发现内存飙升，检查一下你的
useEffect清理函数，或者检查是否有useRef或者全局变量在“非法持有”组件实例或状态。 - SSR (服务端渲染) 与持久化：这也是你题目中提到的“持久化”的背景。在 SSR 中，我们有时希望状态能保留。但在客户端，当组件卸载时，必须确保状态被销毁，否则服务端渲染的残留数据会污染客户端状态。
第九部分：React 18 的并发模式与卸载
随着 React 18 的到来，引入了 useTransition 和 useDeferredValue。这给卸载机制带来了一点小变化。
在并发模式下，React 可以暂停一个更新，切到另一个更新。虽然这主要是针对渲染的，但也意味着 Fiber 树的构建和卸载变得更加复杂。
但是，核心原则没变：
无论 React 多么并发，无论它如何调度任务，当一个 Fiber 节点被标记为 Unmounting 时，React 必须执行清理逻辑，将 memoizedState 设为 null。
并发模式下的“取消”操作，本质上就是比平时更快地触发了 unmountFiber。
第十部分：终极测试——如何验证回收时机？
如果你想亲自验证这个“回收时机”，你可以写一个简单的测试脚本。
// 1. 定义组件
function Child() {
const [data] = useState({ id: 1, value: 'Big Data Object' });
useEffect(() => {
console.log('Child Mounted');
return () => {
console.log('Child Unmounted - Cleaning up');
};
}, []);
return <div>Child</div>;
}
// 2. 模拟卸载
function Parent() {
const [show, setShow] = useState(true);
return (
<div>
{show && <Child />}
<button onClick={() => setShow(false)}>Kill Child</button>
</div>
);
}
// 3. 运行并观察内存
// 当点击 Kill Child 时，React 执行 unmountFiber。
// 此时，Child 组件的 Fiber.memoizedState 变为 null。
// 如果你在 Child 的 cleanup 函数里没有做手脚，那堆对象很快就会被 GC 抓走。观察重点：
当你点击按钮卸载时，你应该立刻看到控制台输出 Child Unmounted。如果你在 cleanup 函数里没有打印 data，那么说明 data 对象已经被切断了引用，不再被 React 控制。
结语：放手吧，让 GC 去工作
React Hooks 的状态持久化，本质上是一个关于所有权的问题。
Fiber 节点拥有 Hook 链表的所有权。当组件卸载时，Fiber 节点通过 unmountFiber 彻底放弃了这份所有权，将 memoizedState 设为 null。
这就是切断引用的时机。它发生在渲染周期的结束，发生在副作用清理函数的执行之时。
而内存的回收，则交给浏览器最强大的工程师——V8 引擎。只要你没有手贱地用 useRef 或闭包把旧状态“绑架”在身边，它们就会回归虚无，成为内存中无用的垃圾。
所以，记住这句话：React 卸载组件，不是为了隐藏它，而是为了送它上路。 做一个合格的 React 开发者，就是要在组件卸载时，确保送它走得干干净净，不要给 GC 增加负担，也不要给自己留下隐患。
好了，今天的讲座就到这里。如果你们在调试内存泄漏时遇到了困难，记得检查一下是不是有哪个 useRef 还在偷偷抱着旧数据不放。谢谢大家！