React Hooks 的调用顺序约束逻辑：从源码视角分析为什么在条件语句中调用 Hook 会导致 Fiber 状态指针发生错位崩溃

各位同学，大家下午好！

今天我们不开 import，也不讲 export，我们讲点“带毒”的东西。我们要聊的是 React Hooks。你们爱它，恨它，或者被它折磨得夜不能寐，对吧？

大家都听说过那个著名的铁律：“Hooks 必须在顶层调用，不能写在 if 里面，不能写在 for 里面，甚至不能在条件语句里署假名出现”。这句话就像宗教戒律一样印在大家的脑子里。但你们有没有想过，为什么？

为什么 React 这么较真？为什么只要你在条件语句里写了一句 if (condition) useState(0)，你的应用就会像断了线的风筝一样——要么报错，要么状态错乱，要么你的数据就那样离奇地“消失”了？

作为一个在源码里像挖地雷一样翻过 Fiber 树的“老司机”，今天我就带大家扒开 React 的内裤，看看这背后的“元凶”。我们不整那些虚头巴脑的 Hello World，我们直接上干货，上源码，上逻辑。

准备好了吗？我们要进入那个只有 React 团队才知道的“幽灵栈”了。

第一章：为什么函数需要“记仇”？

首先，我们要搞清楚 React Hooks 的本质。

传统的 React 组件是“类”的。类就像一个有记忆的傻瓜，它被实例化一次，就在内存里占一块地盘。this.state 就在那块地盘的保险柜里。你调一下 setState，它就去开一下保险柜。简单、粗暴、有效。

但是，Hooks 是函数。函数是什么？函数是无情的过客。每次你调用 <MyComponent />，React 都会重新执行一次那个函数。如果函数是无情的过客，那 React 是怎么让它记住上次的状态的？

答案是：闭包，加上一种极其危险的顺序依赖。

想象一下，你是一个只有一只手的小偷。你走进了一个有很多抽屉的保险箱（Fiber 节点）。每次你进来，你都只能按顺序一个个抽屉摸过去。第一个抽屉放什么，第二个抽屉放什么，必须死板地固定下来。

如果你在第一个抽屉里放了一枚戒指，第二个抽屉里放了一把钥匙。这是安全的。
但如果你在第一次来的时候，发现第一个抽屉被锁住了（条件语句），你就跳过了它，直接去摸第二个抽屉。

下一次你再来的时候，你以为第二个抽屉还在那里，但你忘了，上一次你跳过了第一个抽屉！此时此刻，第二个抽屉其实变成了“第三个抽屉”。如果你还按照上次的顺序去摸，你就摸到了根本不属于你的东西。

这就是我们要讲的逻辑：Fiber 状态指针错位。

第二章：源码探案——`renderWithHooks` 的迷宫

我们要看的是 React 核心源码中的 renderWithHooks 函数。这是每次组件渲染时，React 的“大脑”进来的地方。

看这段伪代码（基于 React 18 源码逻辑）：

function renderWithHooks(current, workInProgress, Component, props) {
  // 1. 建立一个“幻影世界”
  // React 需要在渲染期间生成新的状态，但不能污染当前的真实状态
  renderPhaseHooksListTail = null; 
  currentHook = null; // 这是关键：当前指针，默认指向 null

  // 2. 切换 Dispatcher
  // 这里的 Dispatcher 决定了你是用 useState 的逻辑，还是 useEffect 的逻辑
  ReactCurrentDispatcher.current = HooksDispatcherOnMount;

  try {
    // 3. 执行组件函数
    // 这一刻，所有的 useState, useEffect, useContext 都会从这里开始排队
    const result = Component(props);
    return result;
  } finally {
    // 4. 渲染结束，清理工作
    // 注意：此时 currentHook 指针的位置，决定了下一次渲染的起点
    // 如果不重置，或者逻辑混乱，下一次渲染就会出事
  }
}

看到 currentHook = null 了吗？这就是那个“指针”。每次渲染开始，这个指针必须回到起点。

然后，我们再看看 useState 和 useEffect 在 Dispatcher 里是怎么干的。它们长得差不多，但性格截然不同。

`useState` 的逻辑（纯种水货）：

function basicStateReducer(state, action) {
  return typeof action === 'function' ? action(state) : action;
}

function useState(initialState) {
  // 获取当前指针指向的位置
  const hook = currentHook;

  // 拿出该位置原本存储的数据
  let memoizedState = hook.memoizedState;

  // 更新指针：指针向后移动一位，指向下一个钩子
  // 这是关键的副作用！
  currentHook = hook.next; 

  return [memoizedState, dispatchAction];
}

`useEffect` 的逻辑（投机倒把的混混）：

function useEffect(create, deps) {
  // 也获取当前指针
  const hook = currentHook;

  // ...（省略一堆创建 Effect 对象的代码）...

  // 关键点来了！
  // useEffect 也会调用 currentHook = hook.next;
  // 它把指针向后移了！
  currentHook = hook.next;

  // 并且，它会把这个 Effect 对象“塞”回链表里
  // 使得组件的 memoizedState 指向这个 Effect 对象
}

注意到了吗？ useState 和 useEffect 的移动指针的操作是一样的。

它们都在说：“嘿，我已经读完了第 N 个钩子，现在指针指向第 N+1 个。”

第三章：条件语句引发的“车祸现场”

现在，我们让肇事者——条件语句登场。请看这段著名的“自杀式代码”：

function BadComponent({ shouldRender }) {
  if (shouldRender) {
    const [count, setCount] = useState(0); // 钩子 1
  }

  useEffect(() => {
    // 钩子 2
    console.log('Effect runs. Count is:', count);
  }, []);

  return <div>Hello</div>;
}

我们来模拟一下这个过程。假设 shouldRender 初始为 true。

第一次渲染：

初始化：currentHook 指向 null。
进入条件：if (shouldRender) 为真。
执行 useState：
- currentHook 指向了一个空槽位（或者链表头）。
- 它读取空槽位 -> memoizedState 变成了 0。
- 指针移动：currentHook 从空槽位 -> 指向了链表里的下一个位置（这就是钩子 1）。
执行 useEffect：
- currentHook 指向了钩子 1（刚才那个空槽位）。
- 它读取钩子 1 的数据 -> 创建了一个 Effect 对象。
- 指针移动：currentHook 从钩子 1 -> 指向了链表里的下一个位置（钩子 2）。
返回：组件返回。
- 此时，Fiber 节点的 memoizedState 指向了一个包含 [0, Effect对象] 的链表。

状态良好。指针没有错位。

第二次渲染：悲剧发生时

现在 shouldRender 变成了 false。注意，这是触发崩溃的瞬间。

初始化：currentHook 重置为 null。
进入条件：if (shouldRender) 为假。
- 关键停顿：React 跳过了 useState 的调用！
执行 useEffect：
- currentHook 指向 null。
- 它读取 null。
- 指针移动：currentHook 从 null -> 指向了链表的第一个有效位置。
- 等等！ 因为跳过了 useState，链表的第一个有效位置变成了钩子 1（也就是那个 State 0）。
- useEffect 读取到了 0，但它产生了一个 Effect 对象，并塞了回去。
- 指针移动：currentHook 从钩子 1 -> 指向了钩子 2。
返回：组件返回。

等等，到这里看起来好像还行？ useEffect 活得好好的。

但让我们再往深处看一步。React 的逻辑比这更“毒”。

第二次渲染后的状态链表

由于第二次渲染跳过了 useState，React 的内部链表维护逻辑是：从哪里断开，就重新从哪里接。

memoizedState 链表：[State(0), Effect(从null创建的), State(1)]。
currentHook 指针：停留在 Effect 之后，指向了 State(1)。

第三次渲染：天塌了

现在 shouldRender 又变回了 true。

初始化：currentHook 重置为 null。
进入条件：if (shouldRender) 为真。
执行 useState：
- currentHook 指向 null。
- 它读取 null。
- 指针移动：currentHook 从 null -> 指向了钩子 1。
进入条件：再次为真（同一个条件块）。
- 注意！ 这里我们又要执行 useState！
- currentHook 指向了钩子 1。
- 它读取钩子 1。钩子 1 里面存的是刚才 useEffect 放进去的 Effect 对象（不是数字 0 了！）。
- useState 误以为这是一个 State。它试图把这个 Effect 对象 当作状态来处理。
- 指针移动：currentHook 从钩子 1 -> 指向了钩子 2。
执行 useEffect：
- currentHook 指向了钩子 2。
- 它读取钩子 2。
- …

Boom！崩溃！

你看清楚了吗？因为条件语句跳过了 useState，导致 currentHook 指针在第二次渲染时直接跳过了那个 State，直接从 null 跳到了 Effect。

到了第三次渲染，当条件再次为真时，useState 第一次调用，它以为自己在读新状态，结果指针指着的是上一次残留的 Effect 对象。它把这个 Effect 对象“读取”并“保存”为新的 State。

React 内部在比对 memoizedState 的时候，发现它是一个 Effect 对象，而不是一个数字。类型不匹配！或者更惨的是，当你调用 setCount 时，你试图给一个 Effect 对象赋值，结果要么报错，要么导致后续渲染逻辑彻底崩盘。

这就是指针错位。React 像一个只有单根手指的读卡器，它以为读到了 State A，结果读到了 Effect B，于是它把 Effect B 当作了 State A，把 State C 当作了 Effect B，整个链表就乱了套。

第四章：深入 Fiber 栈——为什么指针这么脆弱？

我们要再往深里挖一层。为什么 React 不用一个数组 const hooks = [] 来存？

因为 Fiber 架构是“栈式”的，但数据流是“链式”的。

在 React 的源码里，current Fiber 节点（正在渲染的节点）和 workInProgress Fiber 节点（正在构建的新节点）是分离的。为了性能，React 需要在同一个 Fiber 节点上复用内存。

想象一下，Fiber 节点是一栋楼。

memoizedState 是一楼的大堂。
Hooks 是楼上各个房间的钥匙，串成了一串。

currentHook 指针，就像是一个拿着这串钥匙的快递员。每次渲染，快递员必须回到一楼大堂，按顺序把钥匙发给各个房间（Hooks）。

如果条件语句说：“前两个房间我不进，直接跳到三楼”，快递员就会直接从大堂跑到三楼。
下一次渲染，快递员从大堂出发，还是跑到三楼。但它手里已经没有二楼钥匙了！

于是，当它到达三楼时，它手里拿的是三楼的钥匙。
它把这个钥匙交给了 useState。useState 以为这是新来的钥匙，打开了一个新房间。
但实际上，这把钥匙是上个渲染周期里，三楼 Effect 房间留下的备用钥匙。

这就是为什么 React 必须强制要求：每一条渲染路径，经过 Hooks 的次数必须严格相等。

如果这次渲染经过了 2 个 Hooks，下次渲染必须也经过 2 个 Hooks，且顺序不能变。不能多，不能少，不能换位置。

第五章：更隐蔽的坑——Effect 挤占 State

除了上面那种条件跳过 useState 的情况，还有一种更常见的坑：在 useState 后面放 useEffect。

function Component() {
  const [state, setState] = useState(0); // 指针 A

  if (someCondition) {
    // 突然插入一个 useEffect
    useEffect(() => console.log("Hello")); // 指针 B
  }

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

让我们追踪一下 currentHook：

渲染 1：
- useState 运行。指针：null -> State。
- useEffect 运行。指针：State -> Effect。
- 返回值：State。
渲染 2：
- useState 运行。指针：null -> State。
- useEffect 运行。指针：State -> Effect。
- 返回值：State。

看起来没问题？错！大错特错！

请记住，useEffect 的执行时机。useEffect 是在渲染之后执行的。

渲染 1：
- React 执行 useState。创建 State 对象。指针指向 Effect。
- React 返回 <div>{state}</div>。组件完成渲染。
- 然后，React 执行 useEffect。useEffect 读取 currentHook（它还在 Effect 那里）。它更新了 Fiber 节点的 memoizedState，把指针扔到了 Effect 链表的后面。
- 此时，Fiber 的 memoizedState 指向了一个包含 State -> Effect 的链表。
渲染 2：
- React 重新执行函数。
- useState 运行。它读取 currentHook（指针从头开始）。
- 它读取到了上一次渲染残留的 Effect 对象！
- 它试图把 Effect 当作 State 来处理。
- useState 返回 [EffectObject, ...]。
- 指针移动到了 Effect 对象的后面。
- useEffect 运行。它读取 currentHook。指针移到了后面。

结果：你的 State 永远变成了一个 Effect 对象。

这就是为什么 React 强调：“Effect 必须在最后”。因为 Effect 是“副作用”，它在渲染流程结束后才介入，它会抢占 currentHook 的位置。如果你在 State 之后调用 Effect，你就打乱了渲染周期的顺序，导致下一次渲染时，State 误读为 Effect。

第六章：如何“破案”与“排雷”

既然我们已经知道了原理，那遇到报错怎么修？其实逻辑很简单：

把所有的 Hooks 提取到条件语句外面。

这是唯一的正解。这不是 React 的缺陷，是 JavaScript 闭包和执行顺序的必然结果。

糟糕的代码（谋杀现场）：

function BadComponent() {
  const [count, setCount] = useState(0);

  if (isLoggedIn) {
    const [token, setToken] = useState(null); // 嫌疑人 A
  }

  useEffect(() => {
    // 指针在这里乱了套
    const data = fetchData(token); // token 可能是 undefined
  }, [token]);
}

正确的代码（现场重建）：

function GoodComponent() {
  // 所有的 Hooks 提到最顶层
  const [count, setCount] = useState(0);

  let [token, setToken] = useState(null);

  if (isLoggedIn) {
    // 在这里初始化，但 Hook 调用必须在顶层
    // 所以我们要在这里把状态提出来
    setToken = (newToken) => {
      token = newToken;
      setToken(newToken); // 触发更新
    };
  }

  useEffect(() => {
    const data = fetchData(token);
  }, [token]);

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

等等，这个写法有点绕。最标准的写法是：

function GoodComponent({ isLoggedIn }) {
  // 1. 提取所有可能的 State
  const [count, setCount] = useState(0);
  const [token, setToken] = useState(null);

  // 2. 在顶层根据条件决定是否初始化（或者使用初始化函数）
  // useState(() => isLoggedIn ? 'token' : null)

  // 3. Effect 必须在最后，且无条件

  useEffect(() => {
    // 这里 token 已经根据 isLoggedIn 有了值
  }, [token]);
}

或者更极端一点，为了安全起见，在顶层定义所有 Hooks，然后通过 useMemo 或条件逻辑来决定是否生效（但这在逻辑上其实也不太对，因为 useMemo 本身也是个 Hook，如果把它放在条件里，同样会触发顺序问题）。

终极真理：不要在条件语句里调用任何 Hook。 无论是 useState, useEffect, useContext 还是 useRef，它们都是“直肠子”，说进就进，说退就退。一旦它们在链表上的位置发生了偏移，React 的指针机制就会失效。

第七章：源码层面的总结——为什么会崩溃？

我们回到源码，总结一下这个“指针错位”导致崩溃的完整路径。

初始化：每次渲染开始，ReactCurrentDispatcher.current 被设置为 HooksDispatcherOnMount（或者 Update）。
遍历：React 顺序执行函数体。
指针逻辑：currentHook 指针按顺序移动。
条件跳跃：如果某个 Hook 调用被 if 阻止，指针就跳过了那个 Hook 在链表中的位置。
后续 Hooks：后续的 Hook 读取了已经被跳过的那个位置的数据（或者跳过后的数据）。
内存错乱：因为 React 期望 State 链表，却读到了 Effect 对象，或者读到了未初始化的内存，导致 Fiber 树的结构与逻辑不符。
运行时错误：
- 类型错误：Cannot read properties of undefined，或者 Effect 对象没有 setState 方法。
- 闭包陷阱：Effect 里读取的 state 是上一次渲染的旧值，因为指针没指到它。
- 无限循环：因为 State 的指针乱了，导致组件在“有状态”和“无状态”之间反复横跳。

结语：对规则的敬畏

各位同学，React Hooks 的设计哲学其实是一种“确定性优先”。React 团队为了性能优化（减少垃圾回收、复用 Fiber），牺牲了一定的灵活性，换取了逻辑的确定性。

这个确定性就是：调用顺序即数据结构。

当你试图打破这个顺序（通过条件语句）时，你实际上是在破坏 React 内部那个精密的“指针游标”。就像你在高速公路上强行插队，交警（React）的计数器会瞬间错乱。

所以，下次当你想写 if (condition) useState() 的时候，请停下你的手。看着那个 use 关键字，想象它是一把锁。你的代码必须在最顶层排好队，一把一把地过，就像进安检一样。别想作弊，React 源码里的那个 currentHook 指针，可是会盯着你的。

代码无小事，指针不乱飞。祝大家的组件都能稳如老狗！

（散会！）