useState 的挂载（Mount）与更新（Update）数据结构
这张图展示 useState 在首次挂载和后续更新时，Fiber 节点上 Hook 对象的创建与复用逻辑。
📝 源码级深度解析（数据结构） ：
useState本质是useReducer的语法糖 ：在 React 源码中，updateState函数实际上指向了updateReducer。唯一的区别在于mountState传入了一个基础状态处理器（basicStateReducer） ，用于处理直接赋值（如setState(5)）或函数式更新（如setState(prev => prev + 1)）。- Hook 节点的持久化 ：首次挂载时创建的 Hook 节点会永久 附着在 Fiber 节点的
memoizedState链表上。后续更新时，React 严格按照调用顺序 （0、1、2...）取出对应的 Hook，这就是 Hooks 必须写在顶层且不能放在if或循环中的根本原因。 - 队列（Queue）的环状结构 ：
queue.pending是一个环状单向链表 ，指向最后一个Update对象。这种设计使得setState的入队操作可以在 O(1) 时间 内完成，且遍历计算时能从pending.next开始找到第一个更新。
dispatchSetState 的入队与调度流程（批处理机制）
这张图展示调用 setState 时，更新对象如何入队，以及调度器如何根据执行上下文决定是否批处理。
📝 源码级深度解析（调度与批处理） ：
- 批处理（Batching）的核心标志 ：React 内部维护一个全局变量
executionContext（位掩码）。当处于EventContext（事件回调）或BatchContext时，setState只会将更新入队并返回，不触发调度 。等到事件回调执行完毕，React 会统一执行flushSyncCallbackQueue或ensureRootIsScheduled进行一次合并渲染。 - React 18 的自动批处理（Automatic Batching） ：React 18 通过
createRoot引入了更强大的批处理能力。即使在setTimeout、Promise或原生事件监听器中，多次setState也会被自动合并。这是因为createRoot将调度器升级为ConcurrentRoot，所有更新都会经过Scheduler统一排队和合并。 - 同步退出批处理（
flushSync） ：如果希望强制在批处理中"跳出"并立即刷新视图，可以使用flushSync(() => setState(...))。这会主动清空当前的更新队列，强制进入同步提交阶段。
useState 的闭包陷阱与陈旧值（Stale Closure）成因
这张图剖析为什么在异步回调中，setState 或读取 state 总是拿到触发时的"快照"值。
📝 源码级深度解析（闭包陷阱） ：
- 闭包（Closure）的僵化性 ：每次函数组件执行时，内部所有的变量（包括
const [state, setState] = useState(0)解构出的state）都是在当前执行上下文 中创建的。setTimeout的回调函数会捕获这个特定的state变量（基本类型值），即使组件后续重新渲染产生了新的state，旧的闭包依然持有旧的内存地址。 - 为什么
setState也会出现陷阱 ：如果在异步回调中调用setState(state + 1)，这里的state同样是被闭包捕获的旧值 。如果连续点击多次，由于累加的基础值始终是旧的0，多次调用setState(0 + 1)最终只会生效一次。 - 解决方案的底层逻辑 ：使用 函数式更新
setState(prev => prev + 1)可以完美解决这个问题。因为processUpdateQueue在计算时，会实时从 Fiber 节点的memoizedState中取出当前最新值 传入action函数，而不是依赖闭包中的陈旧变量。
useState 与 useReducer 的同源关系（源码映射）
这张图展示 useState 是如何作为 useReducer 的"简化版"在 React 底层复用的。
📝 源码级深度解析（同源关系） ：
mountState与mountReducer的细微差别 ：mountState内部会初始化basicStateReducer（基础处理器），这个处理器逻辑是：如果action是函数，则执行action(prevState)，否则直接返回action。而mountReducer允许开发者传入自定义的reducer函数。updateState===updateReducer：在 React 18 源码（ReactFiberHooks.js）中，updateState的代码极其简洁：function updateState(initialState) { return updateReducer(basicStateReducer, initialState); }。这意味着只要组件完成了首次挂载，后续useState的执行逻辑与useReducer完全一致 ，差别仅在于默认使用的reducer规则不同。dispatch函数的固定性 ：无论mountState还是mountReducer，返回的dispatch函数都是在mount阶段创建的，并且通过闭包绑定了当前 Fiber 节点和queue对象。后续的更新中（update阶段），这个dispatch函数的内存地址永远不会变 ，这就是为什么我们可以在useEffect的依赖项中安全地传递setState而不用担心触发无限循环。
四张图总结：useState 的完整画像
| 维度 | 对应图表 | 核心结论 |
|---|---|---|
| 数据结构 | 图 25 | useState 将状态值存储在 Fiber 链表的 Hook 节点中，并附带环状更新队列。 |
| 调度机制 | 图 26 | setState 依赖 executionContext 决定是否批处理，React 18 实现了自动批处理。 |
| 闭包陷阱 | 图 27 | 异步回调捕获的是渲染快照，函数式更新通过读取 Fiber 内存实时值绕开了闭包。 |
| 同源关系 | 图 28 | useState 是 useReducer 的语法糖，后续更新阶段两者代码路径完全一致。 |