React Hooks 链表结构：深度解析 memoizedState 指针在 Fiber 节点上的存储与追踪机制

各位同学，大家好！

欢迎来到今天这场名为“React 内部机制大揭秘”的讲座。我是你们的主讲人，一个在代码堆里摸爬滚打多年的资深工程师。

今天，我们不聊业务，不聊 UI 设计，我们要聊点硬核的。我们要聊的是 React Hooks 的“阿喀琉斯之踵”，或者说，是它的“心脏”——Fiber 架构下的链表结构，以及那个神出鬼没的指针：memoizedState。

如果你觉得 React Hooks 只是 useState 和 useEffect 的简单封装，那你可就太低估 React 团队了。如果你觉得它们只是简单的闭包，那你可能又要掉进坑里了。今天，我们要像解剖一只青蛙（比喻，请不要在实验室这样做）一样，把 React 的内核剖开，看看那个藏在 Fiber 节点里的“秘密花园”到底长什么样。

准备好了吗？系好安全带，我们发车了。

第一部分：Fiber 是什么？为什么我们需要它？

在讲链表之前，我们必须先聊聊 Fiber。很多人听到 Fiber，第一反应是“纤维”。错！大错特错！

Fiber 不是一种材质，它是一个数据结构，更准确地说，它是一个工作单元。

想象一下，你是一个工头，你有一大堆复杂的装修任务要完成（比如渲染一个复杂的组件树）。如果你一次性把所有活儿都干了，累死你也干不完，而且如果中途客户喊停（用户切换标签页），你还得停下来，这效率太低了。

React 的 Fiber 架构就是为了解决这个问题。它把庞大的渲染任务拆解成一个个小任务，挂在一个巨大的“任务清单”上。

每个任务都有一个名字，叫 Fiber 节点。这个节点就像是一个微型的工作站，里面记录了：

这个任务是谁（组件类型）。
它的输入是什么（Props）。
它的输出是什么（UI）。
它的兄弟是谁（兄弟节点）。
它的孩子是谁（子节点）。
最重要的是：它还记住了它的“状态”保存在哪里。

这个“状态保存在哪里”，就是我们今天的主角——memoizedState 指针的藏身之处。

第二部分：Hook 的本质——为什么不是对象属性？

在 Hooks 出现之前，我们用类组件。那时候，状态就是类的成员变量，比如 this.state。简单粗暴，直接访问。

但是，Hooks 出现了。为什么？因为函数组件没有实例，没有 this。如果你在函数里定义变量，每次渲染，变量都会重新声明、重新赋值。那我们怎么保存状态呢？

React 的天才设计师们想出了一个绝妙的主意：把状态挂载到 Fiber 节点上！

但是，一个组件里可能有多个 Hook，比如：

function Counter() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState('React');
  useEffect(() => { ... }, []);
  return <div>{count} - {name}</div>;
}

如果 useState 和 useEffect 都往同一个 memoizedState 里塞数据，那不就乱套了吗？

所以，链表结构登场了！

React 把这些 Hook 按照定义的顺序，串成了一条长长的链子。而这条链子的头，就插在了 Fiber 节点的 memoizedState 属性上。

第三部分：memoizedState 指针——那个神秘的指针

让我们先定义一下 memoizedState 到底是什么。

在 Fiber 节点的源码中，它通常指向一个 Hook 对象。这个 Hook 对象，就是链表中的“节点”。

// 这是一个简化的 Hook 对象结构
class Hook {
  // memoizedState：这是最核心的指针！
  // 对于 useState：它指向当前的 state 值。
  // 对于 useEffect：它指向 effect 对象。
  memoizedState: any; 

  // next：这是链表的“下一节”指针！
  // 它指向组件里的下一个 Hook。
  next: Hook | null;

  // queue：这是更新队列，里面装着待处理的更新。
  queue: UpdateQueue<any>;

  // effectTag：标记这个 Hook 是否有副作用。
  effectTag: number;
}

现在，让我们看看 Fiber 节点怎么存储这个指针。

// Fiber 节点结构
const fiber = {
  // ... 其他属性
  // 这就是那个“金手指”指针！
  memoizedState: null, // 初始为空
  // ...
};

关键点来了：
memoizedState 指针指向的不是下一个 Fiber 节点，而是下一个 Hook 节点。

这就像你在玩串珠子游戏。

你有一个线头（Fiber 节点的 memoizedState）。
你穿上一颗珠子（第一个 Hook）。
这颗珠子上有个小尾巴（Hook 的 next）。
你顺着尾巴穿上了第二颗珠子（第二个 Hook）。
以此类推。

这就是 React Hooks 的物理存储形式。

第四部分：链表的构建过程——初次渲染

好，理论讲完了，我们来看代码。想象一下，当 React 第一次渲染 Counter 组件时，发生了什么？

创建 Fiber 节点：React 创建了一个 Fiber 节点，我们叫它 fiber。
初始化指针：此时，fiber.memoizedState 是 null。
执行 useState(0)：
- React 创建了一个 Hook 对象，我们叫它 hook1。
- hook1.memoizedState 被赋值为 0（初始值）。
- hook1.next 被赋值为 null（这是最后一个 Hook 了）。
- 关键步骤：React 把 hook1 赋值给 fiber.memoizedState。
执行 useState('React')：
- React 创建了第二个 Hook 对象，hook2。
- hook2.memoizedState 被赋值为 'React'。
- hook2.next 指向 hook1。
- 关键步骤：React 把 hook2 赋值给 fiber.memoizedState。

此时的内存结构图如下：

// 伪代码展示内存中的结构
const fiber = {
  type: Counter,
  memoizedState: hook2, // 指针指向了链表的“头”（也就是最后一个定义的 Hook）
  // ...
};

const hook2 = {
  memoizedState: 'React', // 值
  next: hook1,            // 指向下一个 Hook
  queue: { /* ... */ },
  effectTag: 0
};

const hook1 = {
  memoizedState: 0,       // 值
  next: null,             // 链表结束
  queue: { /* ... */ },
  effectTag: 0
};

是不是有点晕？ 别急，我们换个通俗的说法。

把 fiber.memoizedState 想象成一条链子的起始端（虽然它指向的是最后一个 Hook，但在遍历逻辑里，我们需要从头遍历，所以 React 会在内部维护一个全局变量 currentHook 来记录当前遍历到了哪里，这叫“复用链表”机制，我们稍后细说）。

现在，这条链子已经挂载到了 Fiber 节点上。这就是为什么 Hooks 在第二次渲染时还能找到之前的数据。

第五部分：渲染时的追踪——指针如何工作？

现在，用户点击了按钮，调用了 setCount(1)。

调度：React 发现状态变了，开始调度更新。
创建 WorkInProgress Fiber：为了性能，React 不会直接修改旧的 Fiber，而是创建一个临时的“工作 Fiber”（workInProgress）。
复用 Hook 链表：React 偷偷地把 workInProgress.memoizedState 指向了旧 Fiber 的 memoizedState。
- 注意！ 这里不是重新创建 Hook 对象！React 复用了旧 Hook！
执行组件函数：React 重新执行 Counter 组件代码。
- 遇到 useState(0)。
- React 内部有一个全局变量 currentHook，它现在指向 hook1。
- React 读取 hook1.memoizedState（还是 0）。
- React 发现 hook1.queue 里有一个待处理的更新（count + 1）。
- React 处理这个更新，把 hook1.memoizedState 更新为 1。
- React 把 currentHook 移动到 hook2。
- 遇到 useState('React')。
- 读取 hook2.memoizedState（还是 ‘React’）。

为什么不需要重新创建链表？
因为组件函数执行完毕后，函数体内的局部变量就销毁了。如果没有链表，React 就找不回状态了。链表是挂载在 Fiber 上的，而 Fiber 节点在渲染周期结束后通常会被保留（或者被复用），所以链表是持久存在的。

第六部分：链表的更新——指针的“接力赛”

让我们继续追踪更新过程。

当 React 把 hook1.memoizedState 改成了 1 之后，它并没有改变 hook1.next 指向 hook2 的关系。链表的结构依然稳固。

此时，fiber.memoizedState 依然指向 hook2。

但是！ React 为了下一次渲染做准备，它需要更新 fiber.memoizedState 指向的 Hook 对象的 memoizedState 属性。

所以，更新后的状态分布变成了：

hook1.memoizedState: 1
hook2.memoizedState: 'React'

这就是 React 状态更新的本质：
它不是修改了组件函数里的变量，而是修改了 Fiber 节点下挂载的那条链表上的节点的 memoizedState 属性值。

第七部分：useEffect 的双链表结构——进阶挑战

讲了 useState，我们再来看看 useEffect。这可是个“坑王”。

useState 只有一根指针，指向链表。但 useEffect 不一样。它有两个链表！

渲染链表：这是给 useState 用的，我们在上面讲过了。
Effect 链表：这是给 useEffect 用的。

React 在 Fiber 节点上有两个属性：

memoizedState：指向渲染链表的头部。
updateQueue：或者叫 effectQueue，指向 Effect 链表的头部。

为什么要分两个链表？
因为 useEffect 的执行时机和 useState 完全不同。useState 必须在渲染阶段同步完成，而 useEffect 是在渲染完成之后异步执行的。

Effect 链表的结构：

const effectHook = {
  memoizedState: {
    create: () => { /* effect 函数 */ },
    destroy: () => { /* cleanup 函数 */ },
    deps: [/* 依赖数组 */]
  },
  next: null // 指向下一个 Effect
};

当组件第一次渲染时，React 会创建 Effect Hook，把它挂载到 fiber.updateQueue 上。
当组件第二次渲染时，React 会比对依赖数组。如果依赖变了，它会：

执行旧的 Effect 的 destroy 函数（清理旧逻辑）。
更新 Effect Hook 的 memoizedState（挂载新的 Effect）。

追踪机制：
在 useEffect 执行时，React 也是顺着 fiber.updateQueue 这条链表，一个个执行 create 函数的。

第八部分：代码示例——手写一个简易的 Hook 系统

为了彻底搞懂，我们不看源码，我们自己写一个极简版的，看看指针是怎么玩的。

假设我们有一个 fiber 对象和几个 Hook 函数。

// 1. 定义 Fiber 节点
const fiber = {
  memoizedState: null, // 初始为 null
  updateQueue: null,   // 初始为 null
  // ... 其他属性
};

// 2. 模拟 React 的内部状态管理
let hookIndex = 0; // 跟踪当前在链表的哪个位置
let currentFiber = fiber; // 当前操作的 Fiber

// 3. 我们手写一个简易的 useState
function myUseState(initialValue) {
  // 获取当前的 Hook 节点
  // 注意：React 是通过一个全局变量 currentHook 来获取的，这里简化逻辑
  const hook = currentFiber.memoizedState || {
    memoizedState: initialValue,
    next: null
  };

  // 如果是第一次渲染，我们需要把这个 Hook “挂”到 Fiber 上
  if (!currentFiber.memoizedState) {
    currentFiber.memoizedState = hook;
  }

  // 获取当前状态
  let currentState = hook.memoizedState;

  // 定义一个 setter
  const setState = (newValue) => {
    console.log("更新状态啦！");
    hook.memoizedState = newValue; // 修改指针指向的值
    // 这里应该触发调度，但为了演示，我们手动触发一下
    render(); 
  };

  // 指针指向下一个 Hook（虽然我们没真正构建 next 链，但逻辑上要移动）
  currentFiber = { memoizedState: hook }; // 模拟移动

  return [currentState, setState];
}

// 4. 模拟渲染过程
function render() {
  // 每次渲染前重置索引
  hookIndex = 0;
  // 每次渲染前，我们假装创建一个新的 WorkInProgess Fiber
  // 实际上 React 会复用，这里为了演示指针指向的更新，我们重置一下
  // 在真实 React 中，是复用旧 Fiber 的 memoizedState
  currentFiber = fiber; 
}

// 5. 使用
console.log("开始渲染...");
// 第一次渲染
const [count, setCount] = myUseState(0);
const [name, setName] = myUseState('React');

console.log("当前 count:", fiber.memoizedState.memoizedState); // 应该是 0
console.log("当前 name:", fiber.memoizedState.next.memoizedState); // 应该是 React

// 更新
setCount(10);

console.log("更新后 count:", fiber.memoizedState.memoizedState); // 应该是 10

这段代码展示了什么？
它展示了 memoizedState 是如何作为一个“指针”来定位状态的。在这个极简版中，fiber.memoizedState 直接指向了第一个 Hook，而 Hook 对象内部的 memoizedState 存储了实际的值。

在真实的 React 中，这个链条会更长，并且 useEffect 会有一套独立的追踪机制，但核心逻辑——指针指向链表节点，节点存储状态——是一模一样的。

第九部分：React.memo 与指针——优化机制

既然我们讲了链表，那 React 的性能优化组件 React.memo 和 useMemo 是怎么工作的？

React.memo 的核心原理是浅比较 Props。

如果 Props 没变，React 会跳过组件的渲染。跳过渲染意味着什么？
意味着不会执行组件函数，意味着不会遍历 Hooks 链表！

这就导致了一个有趣的现象：
如果你用 React.memo 包裹了一个组件，并且在这个组件里定义了 Hooks，但是因为 Props 不变，组件从未渲染，那么这些 Hooks 的 memoizedState 指针从未被访问和更新！

这就解释了为什么在 React.memo 的子组件里，useState 的初始值永远是最初的值（除非你手动更新了 Fiber 节点上的状态，但这违反了 React 的原则）。

这是一个非常微妙且重要的细节。

第十部分：常见陷阱——闭包与指针的“时差”

最后，我们来聊聊开发者最头疼的问题：闭包陷阱。

为什么你在 useEffect 里拿到的 count 总是旧的？

让我们回到我们的链表模型。

第一次渲染：
- fiber.memoizedState 指向 hook1。
- hook1.memoizedState 是 0。
- useEffect 执行，创建了一个闭包函数，里面捕获了 hook1.memoizedState 的值 0。
用户点击，状态变为 1：
- React 更新了 hook1.memoizedState 的值为 1。
- React 重新执行 useEffect。
- 但是！ React 拿出来的闭包函数，还是第一次渲染时创建的那个闭包函数！
- 这个闭包函数依然指着 hook1.memoizedState 这个内存地址，但这个地址里的值已经变成 1 了（或者取决于 React 的实现细节，它可能存的是旧值）。

真相是：
闭包捕获的是值，而不是指针。虽然 memoizedState 是一个指针，但 React 在创建闭包时，把指针指向的值拷贝了一份存到了闭包里。

这就是为什么你需要依赖数组。如果你告诉 React useEffect 依赖于 count，React 就会：

在下一次渲染时，再次执行 useEffect。
此时，它会重新读取 hook1.memoizedState 的值（现在是 1）。
它会发现依赖变了（0 变 1），所以它会重新执行 useEffect 函数。
这时候，新的闭包里捕获的就是 1 了。

第十一部分：总结——指针的艺术

好了，各位同学，我们的讲座接近尾声。

回顾一下我们今天深入探讨的内容：

Fiber 节点是 React 的物理载体，是任务清单。
memoizedState 是 Fiber 节点上的一个关键指针。
这个指针指向的不是下一个 Fiber，而是指向Hook 链表的头部。
Hooks 通过链表结构串联起来，实现了在函数组件中持久化存储状态。
useState 和 useEffect 共享这一套链表机制（虽然 Effect 有自己的链表），通过指针的移动和值的修改来追踪状态。
闭包问题源于指针指向的值被静态捕获，而非指针本身。

React 的设计非常精妙。它用最简单的数据结构（链表）解决了最复杂的问题（函数组件的状态管理）。它没有使用面向对象那种简单的属性绑定，而是选择了更底层、更灵活、也更难懂的链表结构。

当你下次在控制台打印 fiber 或者调试 React 内部逻辑时，希望你能想起今天讲的这条“链子”。记住，memoizedState 那个指针，指的不是虚空，而是你定义的每一个 Hook 的灵魂所在。

代码不仅仅是写给机器看的，更是写给维护者看的。理解了这些指针，你就理解了 React 的骨架，从此以后，不管是写业务代码，还是看源码，你都会觉得游刃有余。

今天的讲座就到这里，希望大家能喜欢这个关于“指针”的深度解析。如果有任何问题，请在评论区砸过来！谢谢大家！