同学们，大家下午好！欢迎来到今天的“React 源码深度解剖”研讨会。我是你们的讲师，一个在代码堆里摸爬滚打多年的资深工程师。
今天我们不聊业务逻辑，不聊怎么把产品做得五彩斑斓，我们要聊的是 React 里最神秘、最迷人，也最容易让人“踩坑”的领域——Hooks。
你们是不是觉得 Hooks 很爽？不用写类，不用管 this 指向，状态管理像写函数一样简单。但是，你们有没有想过，为什么 React 官方死活强调一句话：Hooks 必须在顶层调用，绝对不能在循环、条件判断或者嵌套函数里调用？
很多人觉得这是“强盗逻辑”，觉得“老子代码写得清清楚楚，我只要在 if 里面加个 useState 不就行了？” 嘿，年轻人，别太自信。如果你这么做了，恭喜你，你刚刚给自己挖了一个深不见底的“捕获陷阱”。
今天，我就要扒开 React 的源码外衣，带大家看看这位“严师”到底在担心什么。我们要讲的东西有点硬核，但我保证，我会用最通俗的语言、最幽默的比喻，带你把 renderWithHooks 这个函数吃干抹净。
准备好了吗？我们要开始上“源码手术台”了。
第一部分：神秘的“链表”与“排队”哲学
首先，我们要明白一个核心概念：React 里的每一个组件，其实就是一个节点。
在 React 的世界里，每个组件对应一个 Fiber 节点。这个 Fiber 节点不仅仅存着 DOM 信息，它还存着组件的“记忆”。大家知道，useState 是用来存状态的，useEffect 是用来存副作用的。那么，这些状态和副作用存放在 Fiber 节点的哪里呢？
答案就在 memoizedState 属性上。
但是，React 很聪明，它没有给每个状态都开一个单独的变量。它搞了个链表。
想象一下，你是一个排队领号的人。React 是那个负责发号的管理员。
- 你调用了
useState(1)，管理员给你发了一个号码牌，上面写着“1”。你把它放在口袋里。 - 你调用了
useState(2)，管理员又给你发了一个号码牌，上面写着“2”，然后把这个“2”挂在“1”的后面。 - 你调用了
useEffect(...)，管理员又发了一个号码牌，挂在“2”的后面。
此时，你的 memoizedState 就变成了：1 -> 2 -> useEffect -> null。
这个链表结构非常重要。为什么是链表？因为 React 需要在渲染的时候，从头部开始，一个个地把这些 Hook 状态取出来，执行一遍，然后更新链表。如果组件重新渲染了，React 就会顺着这条链表，把所有的状态都“重新计算”一遍。
这里的关键在于：管理员（React 渲染器）必须知道，现在轮到谁了。
这就引出了我们今天的第一个核心角色：hookIndex。
第二部分：hookIndex 的奇幻漂流
同学们，请记住这句话：hookIndex 是一个全局计数器。
注意，是全局。而且每次组件开始渲染的时候，它必须重置为 0。
这是什么意思呢？这意味着，无论你的组件函数里写了多少行代码，只要 React 决定开始渲染这个组件，hookIndex 就会清零，然后从 0 开始往下数。
流程是这样的：
- React 执行
renderWithHooks函数。 - 它把当前正在渲染的
Fiber节点的hookIndex重置为 0。 - React 开始执行你的组件函数代码。
- 当它遇到
useState时，它会看一眼hookIndex是多少。如果是 0，它就创建一个新的 Hook 对象，挂载在memoizedState的链表头部，然后把hookIndex加 1。 - 遇到
useEffect，同理。 - 组件函数执行完毕，
hookIndex此时必然是 3（假设你定义了 3 个 Hooks）。
这看起来很完美对吧？顺序分明，逻辑清晰。
但是！如果我们把 Hooks 写在 if 里面呢？或者写在 for 循环里呢？
这就好比你在排队领号的时候，前面的阿姨突然说：“哎呀，我肚子疼，先不领了。” 然后你插了个队，直接走到了第 5 个位置。
这就导致了“捕获陷阱”。
第三部分：捕获陷阱是如何发生的？
让我们通过一个具体的代码示例来看看这个“灾难”是怎么发生的。假设我们有一个极其不规范的组件：
function BadComponent({ shouldRender }) {
if (shouldRender) {
const [count, setCount] = useState(0); // Hook #1
}
const [text, setText] = useState("Hello"); // Hook #2
useEffect(() => {
console.log(text);
}, [text]);
return <div>{text}</div>;
}同学们，请盯着屏幕，想象 React 的内心独白。
第一次渲染：
hookIndex= 0。- 执行到
if (shouldRender)，这里shouldRender是true。 - 调用
useState(0)，React 创建 Hook #1，hookIndex变成 1。 - 代码继续往下走，执行
useState("Hello")。React 创建 Hook #2，hookIndex变成 2。 - 执行
useEffect。React 创建 Hook #3，hookIndex变成 3。 - 结果： 链表结构是
[Hook#1, Hook#2, Hook#3]。text的状态确实存储在 Hook #2 里。
第二次渲染：
hookIndex重置为 0。- 执行到
if (shouldRender)。假设shouldRender还是true。 - 调用
useState(0)。React 创建新的 Hook #1，hookIndex变成 1。 - 代码继续往下走，执行
useState("Hello")。React 创建新的 Hook #2，hookIndex变成 2。 - 结果： 链表结构依然是
[Hook#1, Hook#2, Hook#3]。一切正常。
但是！如果 shouldRender 变成了 false 呢？
第三次渲染（陷阱触发）：
hookIndex重置为 0。- 执行到
if (shouldRender)。现在它是false，代码被跳过。注意！这里什么都没发生！ - 代码继续往下走，执行
useState("Hello")。 - React 看
hookIndex是 0。它心想：“好，现在是第一个 Hook 了。” - 于是，它把刚才
useState(0)创建的那个 Hook 对象（也就是 Hook #1）的memoizedState（状态值）取了出来。 - 关键点来了： React 把 Hook #1 的状态赋值给了
text。 - Bug：
text的值变成了0（来自 Hook #1），而不是"Hello"（来自 Hook #2）。
更可怕的是后续渲染：
第四次渲染：
hookIndex重置为 0。if (shouldRender)是false，跳过。- 执行
useState("Hello")。 - React 看到链表里只有 Hook #1 了（因为 Hook #2 被覆盖了，或者说 Hook #2 不见了，React 以为 Hook #2 就是 Hook #1）。
- React 读取 Hook #1 的状态。这导致
text的值可能还在闪烁，或者更糟糕，导致useEffect的依赖项计算错误。
这就是“捕获陷阱”！ React 以为它在读取 Hook #2，但实际上它读取的是 Hook #1。因为它在链表结构上插队了，导致整个链表的结构发生了错位。
第四部分：源码深潜——renderWithHooks 的逻辑
光说不练假把式。让我们看看源码里到底是怎么实现的。大家打开 React 源码，找到 ReactFiberHooks.js（或者 ReactFiberHooks.old.js，不同版本位置略有不同，但逻辑一致）。
核心函数是 renderWithHooks。我们截取关键片段：
function renderWithHooks(
current,
workInProgress,
Component,
props,
secondArg,
nextRenderLanes
) {
// 1. 核心第一步：重置 hookIndex！
// React 会从 workInProgress fiber 上获取当前的 hookIndex
// 如果是第一次渲染，它是 undefined，初始化为 0
// 如果是重新渲染，React 也会把它的值传回来，但 render 函数内部会重置它
const renderIndex = (workInProgress.renderLanes & Lanes) === 0 ? 0 : 1;
// 注意：不同版本实现细节不同，核心思想是：每次渲染，重置计数器
// 这里的逻辑简化版：
// workInProgress.hookIndex = 0;
// 2. 准备执行组件函数
let children = Component(props, secondArg);
// 3. 渲染结束后的检查
// React 会检查你的组件函数执行了多少次 Hooks 调用
// 如果你的组件函数里调用了 3 次 Hooks，但 render 结束时 hookIndex 是 4
// 那么恭喜你，React 会抛出一个警告："Too many re-renders. React limits the number of renders to prevent an infinite loop."
return children;
}现在，让我们看看具体的 useState 是怎么工作的。源码里有一个非常关键的函数 mountWorkInProgressHook：
function mountWorkInProgressHook() {
const hook = {
memoizedState: null,
baseState: null,
baseQueue: null,
queue: null,
next: null
};
// 关键逻辑：将新 hook 挂载到 workInProgress fiber 的链表上
// 此时，workInProgress.memoizedState 是一个链表头
const existingHook = workInProgress.memoizedState;
if (existingHook === null) {
// 如果链表是空的，新 hook 就是头节点
workInProgress.memoizedState = hook;
} else {
// 如果链表不为空，新 hook 挂在尾巴上
// 这就是链表追加操作
let lastHook = existingHook;
while (lastHook.next !== null) {
lastHook = lastHook.next;
}
lastHook.next = hook;
}
// 核心：hookIndex 自增！
workInProgress.hookIndex++;
return hook;
}同学们，看到了吗？workInProgress.hookIndex++。
这个自增操作是紧跟着 mountWorkInProgressHook 调用之后的。也就是说，每定义一个 Hook，计数器就 +1。
如果在循环或者条件语句里定义，这个计数器就会变得不可预测。React 在下一次渲染时，再次调用 renderWithHooks，再次重置计数器，然后再次执行你的组件函数。
如果你的代码逻辑导致第二次渲染时，Hooks 的定义顺序变了（比如有的 Hook 不见了，有的 Hook 多了），React 就会按照新的顺序去读取链表。
这就好比你在玩俄罗斯方块。
- 第一次渲染，你把方块排成了
I I I I。 - 第二次渲染，你突然把中间的一个
I拿走了，变成了I _ I I。 - 然后你把剩下的方块往下一推。
- 结果是什么？原来的第 2 个方块，现在掉进了第 1 个格子的位置。原来的第 3 个方块，掉进了第 2 个格子的位置。
- 你的数据全乱了。
这就是为什么 React 强制要求 Hooks 在顶层。它要求你的“俄罗斯方块”每次渲染时的形状必须是完全一致的，这样 React 才能把旧数据准确地“搬运”到新数据上。
第五部分：updateWorkInProgressHook 与状态更新
上面的例子我们主要看了状态值的错乱。其实，useEffect 的依赖项也会出问题。
让我们看看 updateWorkInProgressHook 的逻辑（用于更新现有 Hook）：
function updateWorkInProgressHook() {
// 从 workInProgress fiber 上取出来
const hook = workInProgress.memoizedState;
// 注意这里：workInProgress.hookIndex 是从上一次渲染带过来的！
// 它不是 0！
// 1. 获取当前应该更新的是哪一个 hook
const currentHook = current.memoizedState; // 旧链表上的 hook
const nextHook = hook.next; // 新链表上的 hook
// 2. 把当前 hook 挪到 current 链表上（为了保留旧状态）
current.memoizedState = nextHook;
// 3. 把 nextHook 挪到 workInProgress 链表上
workInProgress.memoizedState = currentHook;
// 4. 更新 hookIndex
workInProgress.hookIndex++;
return currentHook;
}如果 Hooks 在条件语句里，workInProgress.hookIndex 的变化就会导致 currentHook 和 nextHook 的引用错乱。
举个 useEffect 的例子：
function EffectComponent({ condition }) {
if (condition) {
useEffect(() => {
console.log("Effect 1");
}, []);
}
useEffect(() => {
console.log("Effect 2");
}, []);
}第一次渲染，condition 为 true。
hookIndex= 0 -> 创建 Effect 1。hookIndex= 1 -> 创建 Effect 2。- 执行：先打印 Effect 1，再打印 Effect 2。
第二次渲染，condition 为 false（假设组件没变，只是内部状态变了，组件重新渲染）。
hookIndex重置为 0。- 跳过
if语句。 hookIndex= 0 -> 尝试更新 Effect 1。hookIndex= 1 -> 尝试更新 Effect 2。
等等，如果第一次渲染时 hookIndex 增长了，那么第二次渲染时 workInProgress.hookIndex 的初始值是多少？它是从 workInProgress 对象上继承来的。
如果第一次渲染时定义了 2 个 Hook，那么 workInProgress.hookIndex 肯定是 2。
第二次渲染时，React 会把这个值传进来。但是，因为你的代码里跳过了第一个 useEffect 的定义，所以你的组件函数里只调用了 1 个 Hook！
这就导致了一个严重的逻辑错误：
React 以为你的组件函数里调用了 2 个 Hook，所以它尝试更新第 2 个 Hook。
但是，你的组件函数里只定义了 1 个 Hook！
React 会去寻找第 2 个 Hook 的引用，结果可能读取到了内存里的垃圾数据，或者导致闭包捕获了错误的值。
更糟糕的是，如果你的 useEffect 依赖了 condition，那么当 condition 变化时，Effect 1 不会更新，Effect 2 可能会错误地触发。
第六部分：为什么是“捕获”陷阱？
为什么官方叫它“捕获陷阱”？
因为在闭包的世界里，函数会“捕获”它周围环境的变量。
当你把 Hooks 放在条件语句里，你就改变了闭包捕获的顺序。
if (x) {
const [state1, setState1] = useState(1);
// 这里闭包捕获了 state1
}
const [state2, setState2] = useState(2);
// 这里闭包捕获了 state2当你把这个函数导出给其他地方使用，或者把这个函数作为回调传下去时：
const handleClick = () => {
// 假设我们在上面那种错误写法下
console.log(state2);
}在第一次渲染时，state2 确实是 2。
在第二次渲染时，如果 Hook 顺序乱了，state2 可能变成了 state1 的旧值。
这就是捕获。你的 handleClick 闭包，捕获了错误的变量。
第七部分：如何破解这个陷阱？（重构艺术）
知道了原理，我们就能对症下药。当你的直觉告诉你“我必须在 if 里面用 Hook”时，其实你的直觉在告诉你：“嘿，你的组件逻辑太复杂了，或者你的状态依赖关系太乱了。”
重构的核心思想只有一个：保持 Hooks 的定义顺序与渲染无关。
错误示范（绝对禁止）：
function BadCode() {
const [data, setData] = useState([]);
if (data.length === 0) {
// 危险！条件性 Hook
useEffect(() => {
fetchData().then(setData);
}, []);
}
return <div>{data.map(...)}</div>;
}正确示范 1：将 Hook 提升到顶层
function GoodCode() {
const [data, setData] = useState([]);
// 1. 数据获取放在顶层，无论什么条件都会执行
useEffect(() => {
fetchData().then(setData);
}, []);
// 2. 渲染逻辑放在下面
if (data.length === 0) {
return <div>Loading...</div>;
}
return <div>{data.map(...)}</div>;
}正确示范 2：使用自定义 Hook 封装条件逻辑
这是最优雅的解决方案。如果你真的需要根据条件来决定是否初始化某个 Hook，请把它封装成一个独立的函数。
function useConditionalEffect(condition, effect) {
useEffect(() => {
if (condition) {
effect();
}
}, [condition, effect]);
}
function GoodCode2() {
const [data, setData] = useState([]);
// 这里是在顶层调用的！符合规则！
useConditionalEffect(data.length === 0, () => {
fetchData().then(setData);
});
return <div>{data.length ? <List data={data} /> : <Loading />}</div>;
}看，通过 useConditionalEffect，我们把“条件判断”从“Hook 定义”中剥离了出来。React 只看到你在顶层定义了一个 Hook，它很开心，因为它不需要维护复杂的链表偏移量。
第八部分：深入 useReducer 与 useContext 的同理性
其实，不仅仅是 useState 和 useEffect，useReducer、useContext 甚至 useRef，都受这个规则约束。
useReducer 的源码里，其实也是通过 mountWorkInProgressHook 和 updateWorkInProgressHook 来管理 memoizedState 的。
function mountReducer(reducer, initialArg, init) {
const hook = mountWorkInProgressHook();
let initialState;
if (init !== undefined) {
initialState = init(initialArg);
} else {
initialState = initialArg;
}
hook.memoizedState = initialState;
const dispatch = function(action) {
// dispatch 的逻辑
};
hook.queue = dispatch;
return [hook.memoizedState, dispatch];
}如果 useReducer 的定义顺序乱了，那么 dispatch 函数里捕获的 state 也会乱。这会导致你明明 dispatch 了 A action，结果更新了 B reducer 的状态。
至于 useContext，虽然它不直接依赖 hookIndex，但它依赖于 Fiber 节点的树结构。如果 Hooks 顺序乱了，导致 memoizedState 链表断裂，那么 useContext 在遍历树查找 Context Provider 时，可能会跳过某些节点，导致上下文值更新不及时。
第九部分：总结与升华（拒绝 AI 味总结）
好了，同学们，今天我们走得很远。
我们从一个简单的 useState 调用出发，深入到了 Fiber 节点的内部，揭开了 memoizedState 链表的神秘面纱。
我们理解了 hookIndex 这个全局计数器在每一次渲染中的重置与自增。
我们亲眼目睹了当 Hooks 滥用 if 语句时，是如何像破坏俄罗斯方块一样，把 React 的内部数据结构搅得天翻地覆的。
核心逻辑回顾：
- 顺序即生命： React 在渲染时，依赖严格的顺序来遍历 Hook 链表。
- 链表结构：
memoizedState是一个单向链表，每个 Hook 是一个节点。 - 全局索引：
hookIndex确保每次渲染都从 0 开始计数，并将 Hook 映射到链表节点上。 - 陷阱： 条件调用导致
hookIndex偏移，使得渲染器读取了错误的节点，导致状态错乱、闭包捕获错误。
所以，下次当你想写 if (x) useState(1) 的时候，请停下来，深呼吸。问自己一个问题：“我的组件逻辑能不能重构一下，把 Hook 提到 if 外面，或者封装成一个自定义 Hook？”
代码写得优雅，不仅是为了别人看，也是为了给 React 这个“管家”省心。React 需要一个井井有条的家，而不是一个乱七八糟的仓库。
好了，今天的源码解剖课就到这里。希望大家在未来的开发中，能够避开这些“捕获陷阱”，写出既符合规范又健壮的 React 代码！
下课！