React Hooks 源码面试：请详细画出 Fiber 节点上的 memoizedState 链表结构及其在重渲染时的移动轨迹

各位同学，大家晚上好！欢迎来到今天的“React 源码大解剖”特别讲座。

我是你们的老朋友，一个在 React 内部世界摸爬滚打多年的资深“摸鱼”专家。今天我们不聊 useEffect 的依赖数组怎么填才不报错，也不聊 React.memo 到底能不能救命。今天，我们要像剥洋葱一样，剥开 React 的外衣，看看那个藏在 Fiber 节点深处、神秘兮兮的 memoizedState 到底是个什么鬼东西，以及它在重渲染时是如何上演一场惊心动魄的“移形换影”大戏。

准备好了吗？系好安全带，我们要钻进 React 的核心里了。

---

第一部分：memoizedState —— 它不是数组，它是链表

很多同学在面试 React 源码时，听到 memoizedState 就头大。为什么？因为它不像 props 那么直观，也不像 state 那么好理解。其实，memoizedState 是 React Hooks 的基石。

如果你问我，React Hooks 的本质是什么？我会告诉你，它就是一个巨大的、嵌套的、单向的链表。

想象一下，你在一个派对上，手里拿着一张号码牌（memoizedState）。这张号码牌上写着你的名字，还贴着一张小纸条（next），告诉你下一个要去哪里。这就是链表。

在 Fiber 节点中，memoizedState 属性就是指向这个链表头节点的指针。

1.1 初始化：单身贵族的诞生

当你在组件里写下 useState(0) 时，React 做了什么？它没有创建一个数组 [0]，它创建了一个节点。

让我们用伪代码来模拟一下这个节点长什么样：

// 这是一个简化的 Fiber 节点结构
function FiberNode() {
  this.type = null;
  this.memoizedState = null; // 链表头指针
  this.updateQueue = null;  // 待处理的更新队列
  this.next = null;         // 链表节点属性
}

// React 内部创建了一个节点
const hookNode = {
  memoizedState: 0, // 当前渲染产生的状态值
  next: null        // 下一个 hook 节点
};

// Fiber 节点挂载这个链表
currentFiber.memoizedState = hookNode;

看懂了吗？ memoizedState 指向一个对象，这个对象里有两个关键属性：

1. memoizedState：存的是当前渲染出的状态值（比如 0）。
2. next：存的是下一个 hook 的节点地址。

1.2 扩展：当 useEffect 加入派对

光有 useState 怎么够？我们还需要 useEffect 来清理旧账。useEffect 也会在 memoizedState 链表里占一席之地。

比如你有这样的代码：

function App() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    console.log(count);
  }, [count]);

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

React 会怎么处理？它会把 useEffect 的回调函数塞进 memoizedState 链表里。

现在的结构变成了这样：

// 第一层：useState
{
  memoizedState: 0,  // 状态值
  next: {
    // 第二层：useEffect
    memoizedState: function cleanup() {}, // effect 回调函数
    next: null // 结束
  }
}

注意看：memoizedState 里的值，在不同类型的 Hook 下含义不同！

• 在 useState 里，它是状态值。
• 在 useEffect 里，它是回调函数。
• 在 useReducer 里，它是 reducer 函数。

这就是为什么你不能随意打乱 Hook 的顺序，否则 React 就会拿着错误的“钥匙”去开错误的“房间”，导致内存泄漏或者逻辑混乱。

---

第二部分：重渲染 —— 指针的接力赛

这是今天讲座的核心：memoizedState 链表在重渲染时是如何移动的？

很多面试题会问：“为什么 useEffect 里的 count 永远是旧的值？” 或者 “为什么 React 状态更新是批量的？”

答案都在这个“移动轨迹”里。

2.1 场景设定

假设我们的组件 App 初始渲染了三次 Hook：

1. useState(0) -> 返回 0
2. useState(1) -> 返回 1
3. useEffect(...) -> 挂载回调

此时，currentFiber.memoizedState 指向的链表结构如下：

[Node 1: count=0] --(next)--> [Node 2: count=1] --(next)--> [Node 3: effectFn]

2.2 触发重渲染

现在，你点击了按钮，调用了 setCount(2)。React 开始执行下一次渲染。此时，React 携带了一个新角色登场了：workInProgressFiber。

这是新树，是正在构建中的树，是“正在进行时”。

2.3 移动轨迹详解

当 React 重新执行 App 函数组件时，它并没有把旧的链表删了，它只是创建了一个新的链表，然后把旧的链表“借”过来用。

步骤一：清空新指针

workInProgressFiber.memoizedState = null; // 新节点暂时是空的

步骤二：复制旧链表（这是关键！）

React 开始遍历旧的 currentFiber.memoizedState 链表，并把每一个节点复制到新链表中。

1. 处理第一个 Hook (useState(0))：

   • 旧节点：Node 1 (count=0)。
   • 新节点：NewNode 1 (count=0)。
   • 移动：workInProgressFiber.memoizedState 指向 NewNode 1。
   • 更新：因为我们要更新 count，React 发现 updateQueue 里有一个新的更新（值为 2）。于是，它修改了 NewNode 1.memoizedState 的值为 2。
   • 结果：新链表第一个节点变成了 2。

   [NewNode 1: count=2] --(next)--> [???]

2. 处理第二个 Hook (useState(1))：

   • 旧节点：Node 2 (count=1)。
   • 新节点：NewNode 2 (count=1)。
   • 移动：NewNode 1.next 指向 NewNode 2。
   • 更新：updateQueue 里没有这个状态的新更新，保持不变。
   • 结果：新链表第二个节点还是 1。

   [NewNode 1: count=2] --(next)--> [NewNode 2: count=1] --(next)--> [???]

3. 处理第三个 Hook (useEffect)：

   • 旧节点：Node 3 (effectFn)。
   • 新节点：NewNode 3 (effectFn)。
   • 移动：NewNode 2.next 指向 NewNode 3。
   • 结果：新链表第三个节点是 effect 回调。

   [NewNode 1: count=2] --(next)--> [NewNode 2: count=1] --(next)--> [NewNode 3: effectFn]

步骤四：完成置换

当渲染函数执行完毕，React 会把 workInProgressFiber.memoizedState 赋值给 currentFiber.memoizedState。

最终状态：

• 旧链表（内存里还在，等着被垃圾回收）：[0] -> [1] -> [effect]
• 新链表（现在挂在 currentFiber 上了）：[2] -> [1] -> [effect]

---

第三部分：为什么 useEffect 里拿不到新值？（深度解析）

好，现在我们来聊聊那个经典的面试题。

你在 useEffect 里打印 count，发现它还是 0，而不是你刚设置的 2。这又是为什么？

让我们回到上面的“移动轨迹”。

在重渲染过程中，React 执行了 App 函数。此时，组件内部访问 count 时，它去哪找？
它去的是 workInProgressFiber.memoizedState 指向的新链表。

但是！React 的执行顺序是这样的：

1. React 创建 workInProgressFiber。
2. React 开始执行 App 函数。
3. 在执行 App 函数的代码时，它读取 useState(0) 返回的值，赋给了局部变量 count。
4. 此时，React 还没有更新 NewNode 1.memoizedState 的值为 2（因为更新逻辑是在渲染阶段处理的，而不是在执行函数体时处理的，虽然它们很近，但在 Hook 内部，memoizedState 的更新是同步的，但 useEffect 的注册是异步的）。
5. 等函数执行完了，React 才去遍历 updateQueue，把 count 改成 2。
6. 最后，React 才把 useEffect 的回调函数注册到链表里。

这里有个时间差！

当 React 把 useEffect 回调注册到链表里时（也就是 NewNode 3 被创建并挂在链表上时），NewNode 1 的值可能还没来得及被更新，或者更准确地说，闭包捕获的是函数执行那一刻的引用。

修正理解：实际上，在 renderWithHooks 中，React 会同步更新 memoizedState。
让我们重新审视那个时间线：

1. renderWithHooks 开始。
2. 调用 useState(0)。React 检查 updateQueue，发现有新值 2。立即修改 workInProgressFiber.memoizedState 指向的节点的 memoizedState 为 2。
3. 函数体执行，const count = useState(0)[0]。此时 count 是 2。
4. 调用 useEffect(() => console.log(count), [count])。
5. React 把回调函数放入 memoizedState 链表的下一个节点。

那么，为什么 useEffect 打印的还是旧值？

因为 useEffect 的依赖数组 [] 是空的！
虽然 React 把回调函数放进去了，但是当你点击按钮触发重渲染时，React 会对比依赖数组。

• 依赖数组是 []。
• 当前渲染产生的值（闭包里的 count）是 2。
• React 发现依赖没变，所以不会重新执行 useEffect 的回调函数。

如果依赖是 [count] 呢？
如果依赖是 [count]，React 会发现依赖变了（从 0 变成了 2）。
这时候，React 会去 workInProgressFiber.memoizedState 链表里找依赖值。

1. 找到第一个节点：值是 2（新值）。
2. 找到第二个节点：值是 1（新值）。
3. 找到第三个节点：值是 useEffect 回调函数。
4. React 会把 useEffect 回调函数和依赖数组 [2, 1, ...] 进行比对。
5. 如果回调函数引用没变，React 就不执行。

真正执行 useEffect 的情况：
只有当 useEffect 回调函数的引用发生改变，或者你修改了依赖数组里的值导致 React 认为需要重新执行时，useEffect 才会跑起来。

---

第四部分：useReducer 的特殊移动轨迹

既然聊到了 memoizedState，我们就不能放过 useReducer。它是 useState 的升级版，也是 memoizedState 链表结构最复杂的版本。

4.1 useReducer 的节点结构

useReducer 的节点结构稍微有点不同，它通常包含两个部分：memoizedState（当前状态）和 baseState（基础状态）。

{
  memoizedState: 0, // 当前显示的状态
  baseState: 0,     // 基础状态（用于计算 diff）
  next: {
    // 下一个 hook
  }
}

4.2 updateReducer 的移动逻辑

当你在 useReducer 里派发一个动作时，updateQueue 会收到一个 update 对象。

const update = {
  memoizedState: null, // 初始是 null
  action: (state) => state + 1,
  next: null
};

React 会把这个 update 对象插入到 fiber.updateQueue 中。

在重渲染时，React 会遍历 updateQueue，并从 memoizedState 链表中取出值，结合 update 的 action 来计算新值。

移动轨迹示例：

1. 初始渲染：memoizedState 指向一个节点，值为 0。
2. Dispatch：updateQueue 变成 [update1, update2]。
3. 重渲染：
   • React 读取 memoizedState 的值 0。
   • 应用 update1.action -> 变成 1。
   • 应用 update2.action -> 变成 2。
   • React 更新链表节点的 memoizedState 为 2。

这个过程就是所谓的“移动轨迹”：数据从 memoizedState 流向 updateQueue，经过计算后，再流回 memoizedState。

---

第五部分：实战演练 —— 画出那个“鬼畜”的链表

为了让大家彻底明白，我们来手写一个极其简化的 React 渲染器，模拟 memoizedState 的移动。

假设我们有两个状态和一个 effect。

// 模拟 Fiber 节点
const fiber = {
  memoizedState: null // 初始为空
};

// 1. 初始渲染：执行 Hook
function renderApp() {
  // 初始化第一个状态
  fiber.memoizedState = {
    memoizedState: 0, // useState(0)
    next: null
  };

  // 初始化第二个状态
  fiber.memoizedState.next = {
    memoizedState: 1, // useState(1)
    next: null
  };

  // 初始化 Effect
  fiber.memoizedState.next.next = {
    memoizedState: function() { console.log("Effect Run"); }, // useEffect
    next: null
  };

  console.log("初始渲染后的链表结构：");
  console.log(fiber.memoizedState);
  // 输出: { memoizedState: 0, next: { memoizedState: 1, next: { memoizedState: f(), next: null } } }
}

// 2. 触发状态更新：setCount(2)
function updateState(newState) {
  // React 创建一个新的 workInProgress Fiber
  const workInProgress = {
    memoizedState: null
  };

  // 复制旧链表
  let oldNode = fiber.memoizedState;
  let newNode = workInProgress;

  while (oldNode) {
    // 创建新节点，默认复制旧值
    let newNodeCopy = {
      memoizedState: oldNode.memoizedState,
      next: null
    };

    newNode.memoizedState = newNodeCopy;

    // 如果是第一个节点，修改为新值
    if (newNode === workInProgress) {
      newNodeCopy.memoizedState = newState;
    }

    // 指针移动
    oldNode = oldNode.next;
    newNode = newNodeCopy;
  }

  // 完成置换
  fiber.memoizedState = workInProgress.memoizedState;

  console.log("状态更新后的链表结构：");
  console.log(fiber.memoizedState);
  // 输出: { memoizedState: 2, next: { memoizedState: 1, next: { memoizedState: f(), next: null } } }
}

代码解析：
看到没有？这就是移动轨迹！
我们并没有改变旧的节点，我们创建了一个全新的节点（newNodeCopy），把旧的值拷贝过来，然后修改第一个节点的值，最后把旧链表的“头”拔了，换成新链表的“头”。

这就是 React 保持状态隔离、实现并发渲染的秘诀。它不是在原地修修补补，而是像搭积木一样，重新构建了一套结构。

---

第六部分：深度陷阱 —— 为什么 Hook 顺序不能变？

现在我们回到最开始的问题。为什么 memoizedState 是一个链表？为什么它不能是一个数组？

如果它是一个数组 const state = [0, 1]，那么当你重渲染时，你只需要修改数组的索引 state[0] = 2 就行了。

但因为是链表，React 必须知道：

• 第一个节点是 useState 的结果。
• 第二个节点是 useState 的结果。
• 第三个节点是 useEffect 的回调。

如果你把 useEffect 挪到了 useState 后面：

function App() {
  // ... useState ...
  // ... useState ...
  return <div />;
}
useEffect(() => {}); // 移到后面了！

React 在初始化时，会认为 useEffect 是第四个节点。但在重渲染时，因为组件函数执行顺序变了，useEffect 又变回了第三个节点。

React 会拿着“第三个节点”的钥匙，去开“第四个节点”的门。这会导致内存泄漏，或者 useEffect 里的闭包引用了错误的上下文。

链表结构保证了 Hook 的顺序在渲染过程中是固定的（只要你不改代码），React 就能通过遍历链表，准确无误地找到每个 Hook 对应的节点，进行更新。

---

第七部分：终极面试题 —— useLayoutEffect 的时机

既然聊到了 useEffect，怎么能不提 useLayoutEffect？

useLayoutEffect 的移动轨迹和 useEffect 是一样的。它也是插入到 memoizedState 链表中。

区别在于执行时机。

• useEffect：在浏览器绘制完成后执行（异步）。此时 memoizedState 链表已经更新完毕，DOM 已经渲染。
• useLayoutEffect：在浏览器绘制之前执行（同步）。此时 memoizedState 链表已经更新完毕，DOM 已经渲染，但还没显示给用户。

在 useLayoutEffect 里修改 DOM，用户会先看到 DOM 变了（绘制前），然后再看到 DOM 变了（绘制后）。这会导致页面闪烁。

面试加分项：
如果你能画出 useLayoutEffect 的移动轨迹，并解释它和 useEffect 在链表中的位置完全一致，只是在 commit 阶段执行的时机不同，面试官会对你刮目相看。

---

结语：链表的哲学

好了，同学们，今天的讲座要接近尾声了。

我们回顾一下今天的重点：

1. memoizedState 是一个链表，不是数组。
2. 重渲染时，React 会创建一个新链表，复制旧链表结构，然后修改新链表中的节点值。
3. 闭包陷阱是因为链表节点的更新和回调函数的注册存在微妙的时序关系。
4. Hook 顺序不能变，是因为链表结构依赖于遍历顺序。

React 的设计哲学里，充满了这种“链式”思维。从事件委托到虚拟 DOM 的 Diff 算法，再到 Hooks 的链表管理，一切都是为了可预测性。

当你下次看到 console.log(fiber.memoizedState) 时，不要只看到一个奇怪的指针。你要看到那一串排着队、等待着被更新、被渲染、被消费的节点。

希望这篇文章能帮你把 memoizedState 的链表结构刻进脑子里。记住，不要死记硬背代码，要理解那个“移动”的过程。那个过程，就是 React 的心跳。

下课！大家记得回去多刷几道题，别让链表断了！