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.1useReducer的节点结构

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

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

4.2updateReducer的移动逻辑

当你在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 的心跳。

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