React Hooks 限制分析：从源码视角解释，为什么在 if 语句中调用 Hook 会导致状态与 Fiber 指针错位？

各位同学，大家好！

欢迎来到今天的“React 内核解剖室”。我是你们的讲师。今天我们要聊的话题，绝对会让每一个 React 开发者感到头皮发麻，却又不得不深究——那就是：为什么 React Hooks 像个严厉的教导主任，死活不允许你在 if 语句里调用 useState？

很多同学可能会说：“不就是报个错吗？我遵守规则不就行了？”

错！大错特错！这不仅仅是“规则”，这是 React 为了保命而设下的“防火墙”。如果你不理解这背后的底层逻辑，哪怕你遵守规则，在某些极端的并发场景下，你的程序依然会像喝醉了酒一样，莫名其妙地丢失状态、渲染错位。

今天，我们不谈 API，不谈业务，我们要把 React 的源码扒开，看看那个藏在 Fiber 节点背后的“链表”到底发生了什么。

准备好了吗？让我们把代码编译器打开，把大脑皮层放松，开始今天的深度游。

---

第一章：Fiber 节点与“衣柜理论”

首先，我们要建立一个新的世界观。在 React 16 之前，组件的渲染是同步的、线性的。但在 React 16 之后，为了实现并发模式，React 引入了一个核心概念——Fiber。

你可以把每个 React 组件实例，想象成挂在 DOM 树上的一个 Fiber 节点。这个节点不仅仅包含组件的 props 和 state，它还包含了一个至关重要的属性：memoizedState。

这个 memoizedState 是什么？它是一个指针。

想象一下，每个 Fiber 节点都有一个衣柜。memoizedState 就是这个衣柜的门把手。当你调用 useState 时，你并不是在空气中凭空捏造了一个变量，而是在这个 Fiber 节点的衣柜里，挂上了一件衣服（State）。

而且，React 的 Hooks 不仅仅是挂衣服，它们是挂成了一条链。

链表结构长这样：

// 这是一个伪代码结构
fiberNode.memoizedState = {
  memoizedState: 当前状态值,
  next: {
    memoizedState: 下一个状态值,
    next: {
      memoizedState: 下一个状态值,
      next: null // 链表结束
    }
  }
};

这就是 React Hooks 的“宪法”：调用顺序必须严格一致。

每一次组件渲染，React 的渲染器（Renderer）会遍历你的组件函数。遇到 useState，它就去衣柜里挂一件新衣服；遇到 useEffect，它就去挂一个副作用。

---

第二章：正常流程——完美的排队

让我们先看看一个完美的、没有 if 的组件是怎么工作的。

假设我们有一个组件 MyComponent，它在渲染时依次调用了两个 useState。

function MyComponent() {
  // 第1次渲染：调用 Hook 0
  const [countA, setCountA] = useState(0);

  // 第2次渲染：调用 Hook 1
  const [countB, setCountB] = useState(10);

  return (
    <div>
      A: {countA}, B: {countB}
    </div>
  );
}

渲染过程模拟：

1. 渲染阶段 1：

   • React 开始渲染 MyComponent。
   • 它创建了一个新的 workInProgressFiber（正在工作的 Fiber）。
   • 它调用 MyComponent。
   • 遇到 useState(0)：React 创建一个 Hook 节点，把值 0 存进去，把这个节点的地址赋给 workInProgressFiber.memoizedState。
   • 遇到 useState(10)：React 创建下一个 Hook 节点，把值 10 存进去，挂在第一个节点下面。
   • 结果：Fiber 的 memoizedState 指向 Hook 0，Hook 0 的 next 指向 Hook 1。

2. 更新阶段 1：

   • 用户点击了按钮，触发 setCountA(1)。
   • React 不会重新从头渲染组件函数，而是利用之前保存的 Fiber 信息。
   • 它会遍历 memoizedState 链表。
   • 第1个节点是 Hook 0，它知道这是 countA，于是更新 memoizedState 为 1。
   • 第2个节点是 Hook 1，它知道这是 countB，保持不变。
   • 结果：完美匹配，UI 正确更新。

---

第三章：故障点——当条件语句介入

现在，我们要把那个“捣乱分子”请进来——if 语句。

假设你是个极其不自律的程序员，你想在条件满足时才初始化状态。

function MyComponent() {
  const [countA, setCountA] = useState(0);

  if (Math.random() > 0.5) {
    // 只有 50% 的概率会进入这里
    const [countB, setCountB] = useState(10);
  }

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

这就好比你买了一张电影票（Fiber），进场后，售票员（React 渲染器）让你排队检票。

• 场景 A（第一次渲染，运气好，random > 0.5）：

  • 你走到了 Hook 0 的窗口，领了票 A。
  • 你走到了 Hook 1 的窗口，领了票 B。
  • Fiber 持有： [Hook 0, Hook 1]。

• 场景 B（第二次渲染，运气不好，random <= 0.5）：

  • 你再次进场。
  • 你走到了 Hook 0 的窗口，领了票 A。
  • 等等！ 因为 if 条件不满足，Hook 1 的窗口被跳过了！你直接退场了。
  • Fiber 持有： [Hook 0]。

问题来了：Fiber 节点是个顽固的家伙。
当你第一次渲染完，Fiber 节点里其实已经记录了 [Hook 0, Hook 1]。虽然第二次渲染只用了 Hook 0，但 Fiber 节点里的“仓库”里依然躺着 Hook 1 的旧数据。

---

第四章：源码视角的灾难——指针错位

现在，我们来看看最核心的问题：状态更新与 Fiber 指针的错位。

假设在第一次渲染（random > 0.5）时，我们更新了 countB。

1. 触发更新： 你调用了 setCountB。

2. 查找链表： React 开始遍历 memoizedState 链表。

   • 它找到 Hook 0（countA）。跳过。
   • 它找到 Hook 1（countB）。找到目标！更新 countB 为 11。
   • 此时 Fiber 链表状态： [Hook 0, Hook 1(updated)]。

3. 再次渲染（random <= 0.5）：

   • React 重新执行 MyComponent。
   • 它调用 useState(0)，挂上 Hook 0。注意，这是一个新的 Hook 实例！
   • 因为条件不满足，它没有挂上 Hook 1。
   • 此时 Fiber 链表状态： [Hook 0(new), null]。

最致命的时刻到了：并发更新。

假设 React 处于并发模式，或者仅仅是因为某种原因，React 决定把刚才那个更新 countB 的任务，重新拿回来执行。或者更常见的情况是，严格模式。

在严格模式下，React 会故意运行两次渲染：

• 渲染 1： 调用 Hook 0，调用 Hook 1。
• 渲染 2： 调用 Hook 0（清空了之前的 Hook 1），调用 Hook 1（新的）。

让我们看看 dispatchAction（状态分发函数）在源码里是怎么找状态的。

这是简化版的源码逻辑：

function dispatchAction(fiber, action) {
  // 1. dispatchAction 是闭包，它知道它是在哪个 Hook 上注册的。
  // 假设这个 dispatchAction 是 Hook 1 注册的（来自第一次渲染）。

  let hook = fiber.memoizedState;
  let i = 0; // 计数器，代表当前是第几个 Hook

  // 2. 关键循环：遍历链表
  // React 期望：遍历多少次，就更新第几个 Hook。
  while (hook) {
    if (i === hook.index) {
      // 找到了！
      hook.memoizedState = action;
      return;
    }
    hook = hook.next;
    i++;
  }

  // 3. 如果遍历完了链表，没找到对应的 Hook...
  // 这里的逻辑通常会报错或者导致严重的逻辑错误。
}

灾难现场重现：

1. 第一次渲染：

   • Hook 0 创建，注册 dispatchA。
   • Hook 1 创建，注册 dispatchB。
   • fiber.memoizedState = Hook 0 -> Hook 1。

2. 第二次渲染（条件改变）：

   • Hook 0 创建（覆盖了旧的）。
   • Hook 1 被跳过！
   • fiber.memoizedState = Hook 0 -> null。

3. 触发 dispatchB：

   • dispatchB 被调用。它拿着 fiber.memoizedState 开始遍历。
   • 第一轮： 找到 Hook 0（i=0）。dispatchB 想：“这不是我的 Hook（i != 1）”，继续遍历。
   • 第二轮： hook.next 是 null。遍历结束。
   • 结果： dispatchB 跑到了 Hook 0 里面！它把 Hook 0 的状态给改了！或者它什么都没做，直接退出了。

这就是错位！

因为 Fiber 节点里残留了旧链表的长度（Hook 0 -> Hook 1），而新的渲染只生成了 Hook 0。当旧的 dispatch 函数试图通过“计数”的方式去定位状态时，它数到了 Hook 0，然后发现“我不属于这里”，于是跳过，继续找。结果链表断了，它找不到 Hook 1 了。

或者更糟：
如果 React 的双 Fiber 栈机制（Concurrent Mode）介入，第一次渲染创建了 Hook 1，第二次渲染创建了 Hook 0。当你再次更新时，dispatch 函数在 Fiber 里看到的链表结构是 [Hook 0, Hook 1]，但它期望的顺序可能因为 Fiber 树的复用而变得混乱。这种情况下，React 根本无法确定该更新哪个 Hook，直接抛出异常或者导致 UI 不一致。

---

第五章：为什么不能“修复”它？

你可能会想：“React 大厂，几百号人，就不能写个检测机制吗？检测到条件语句里调用了 Hook，就报错。”

哎，同学，你低估了 React 的野心，也高估了它的“修复”能力。为什么 React 不允许在 if 里用 Hook，是因为并发渲染。

在并发模式下，同一个 Fiber 节点可能会被渲染两次！

• 渲染 A： 条件为真，创建了 Hook 1。
• 渲染 B： 条件为假，没有创建 Hook 1。

此时，如果渲染 A 正在计算，渲染 B 也在计算。它们都在操作同一个 Fiber 节点的 memoizedState。

如果 React 允许在 if 里用 Hook，它必须解决一个数学难题：如何让一个 Fiber 节点同时支持两条不同长度的 Hook 链表？

React 的设计哲学是不可变性和确定性。它不能让一个组件的渲染结果随着时间推移而改变（比如第一次渲染有 2 个 State，第二次渲染有 1 个 State）。

一旦 Hook 的数量在两次渲染之间发生变化，Fiber 节点的结构就变了。React 就必须重新构建整个 Fiber 树。这会导致性能急剧下降，甚至导致状态丢失。

所以，React 选择了最简单粗暴也最安全的方式：硬性禁止。只要你违反了“调用顺序一致性”的规则，我就直接报错，绝不让你进入渲染队列。

---

第六章：深入源码细节——renderWithHooks

让我们再深入一点，看看 renderWithHooks 这个核心函数是如何工作的。这是 React 源码里的“心脏”。

function renderWithHooks(
  current,    // 当前 Fiber（正在恢复渲染的那个）
  workInProgress, // 新的 Fiber（正在构建的那个）
  Component,
  props,
  secondArg
) {
  // 1. 初始化 Hooks
  workInProgress.memoizedState = null;
  workInProgress.updateQueue = null;
  workInProgress.flags = 0;

  // 2. 设置指针
  let nextCurrentHook = current !== null ? current.memoizedState : null;
  let nextWorkInProgressHook = workInProgress.memoizedState;

  // 3. 核心循环
  // React 会把 Component 函数里的代码，一行一行地执行
  let children = Component(props, secondArg);

  // 4. 关键检查
  // 如果我们在执行 Component 的过程中，修改了 workInProgressHook 的引用
  // 比如你在某个回调函数里又调用了 useState...
  // React 会检查是否违反了规则。

  // 而对于 if 语句：
  // 如果 Component 里的代码逻辑改变了，导致 Hook 的数量变化，
  // 那么上面的 while 循环虽然会跑完，但 nextCurrentHook 和 nextWorkInProgressHook 的状态就乱了。
  // React 无法确保 current 的旧 Hook 链表和新 Hook 链表长度一致。

  // 5. 返回结果
  return children;
}

在这个循环里，useState 的实现大致是这样的：

function useState(initialState) {
  // 获取当前指针
  let hook = workInProgressHook;

  // 如果是第一次渲染，创建新节点
  if (!hook) {
    hook = {
      memoizedState: initialState,
      next: null,
      queue: null,
      baseState: null,
      baseQueue: null,
      deps: null,
      index: 0 // 这是一个隐藏属性，记录 Hook 的索引
    };
    workInProgressHook.next = hook;
    workInProgressHook = hook;
  } else {
    // 如果不是第一次，复用旧节点
    // ... 更新逻辑
  }

  return hook.memoizedState;
}

你看，workInProgressHook 是一个全局变量（在函数作用域内）。

如果代码里有 if：

function Component() {
  useState(1); // 指针指向 Hook 0
  if (x) {
    useState(2); // 指针指向 Hook 1
  }
  // ...
}

如果 x 在渲染过程中变了，或者 Fiber 复用导致逻辑变了，workInProgressHook 就会乱跳。React 无法在渲染结束后，准确地把 current.memoizedState（旧链表）和 workInProgress.memoizedState（新链表）对齐。

---

第七章：代码示例——直观感受“错位”

让我们写一段代码，模拟这种“灾难”。

// 假设这是 React 的简化版
let workInProgressHook = null;

function useState(initialState) {
  if (!workInProgressHook) {
    workInProgressHook = { value: initialState, next: null };
  }
  return workInProgressHook.value;
}

function render(Component) {
  workInProgressHook = null;
  return Component();
}

// --- 用户代码 ---

let renderCount = 0;

function App() {
  const [a, setA] = useState('Init A');

  renderCount++;
  console.log(`--- Render ${renderCount} ---`);
  console.log(`Current a: ${a}`);

  if (renderCount === 1) {
    // 第一次渲染：条件为真，调用 Hook B
    const [b, setB] = useState('Init B');
    console.log(`Current b: ${b}`);
    // 这里如果调用 setB，它会修改 workInProgressHook 的值
    // 但是 renderCount++ 导致第二次渲染时条件为假
  }

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

// 1. 第一次渲染
render(App);
// 输出:
// --- Render 1 ---
// Current a: Init A
// Current b: Init B

// 2. 第二次渲染
// 注意：这里我们模拟 Fiber 复用，或者 React 重新调用了 App
render(App);
// 输出:
// --- Render 2 ---
// Current a: Init A
// (没有 b)

// 3. 假设我们在第一次渲染后，试图更新 b
// setB('Updated B');
// 此时，React 会去查找 b。
// 它会发现 workInProgressHook 的链表结构变了。
// 第一次渲染后：Hook A -> Hook B
// 第二次渲染后：Hook A
// setB 找不到 Hook B，或者 Hook B 被挂在了 Hook A 下面，导致数据污染。

这就是为什么 React 会报错：“React Hook ‘useState’ cannot be called inside a conditional statement.”

---

第八章：总结与思考

好了，同学们，今天的讲座接近尾声。我们为什么要在 if 里不能用 Hook？

总结一下：

1. 链表结构： Hooks 本质上是一个 Fiber 节点内部的单向链表。
2. 顺序依赖： React 依赖固定的调用顺序来维护这个链表。
3. 指针错位： if 语句导致链表长度在渲染间变化。当旧的 dispatch 函数试图通过遍历链表来更新状态时，它会发现链表变短了，或者指针指向了错误的位置。
4. 并发模式： 在并发模式下，同一个组件可能会被渲染多次，且条件可能变化。React 无法在同一个 Fiber 节点上维护多条动态变化的链表，为了防止状态丢失和逻辑混乱，它选择了禁止。

最后，给各位的建议：

不要试图去“Hack” React Hooks。不要写 if (process.env.NODE_ENV === 'development') 来绕过规则。不要在组件内部写复杂的逻辑来决定是否调用 Hook。

把你的状态初始化代码，全部放在组件函数的最顶层。让它们像排队的士兵一样，整整齐齐地列队。这是 React 的契约，也是你代码健壮性的基石。

如果你真的需要在条件中初始化状态，请使用惰性初始化函数：

// ✅ 正确的做法：使用函数形式
function MyComponent() {
  const [count, setCount] = useState(() => {
    // 这个函数只在第一次渲染时执行
    if (Math.random() > 0.5) {
      return 10;
    }
    return 0;
  });

  // ❌ 错误的做法：直接调用
  // if (Math.random() > 0.5) {
  //   const [count, setCount] = useState(10);
  // }
}

记住，useState 的参数可以是函数，这个函数是在渲染阶段执行的，它不会破坏 Hook 的调用顺序。这给了我们灵活性，同时保留了链表的完整性。

希望大家以后写代码时，看到 if 语句里的 useState 就能想起今天讲的内容，想起那个在 Fiber 链表中迷路的指针，然后老老实实地把代码移到外面去。

今天的讲座就到这里，下课！