如何理解闭包在 React Hooks（如 useState）中的应用原理
先明确一个核心观点：闭包并非 React Hooks 的某种“副作用”，恰恰相反，它是整个 Hooks 机制得以正常运转的底层基石。 没有闭包，useState 连上一次的状态值都存不住，整个函数组件模型也就无从谈起了。
闭包是 React Hooks 正常工作的底层前提，useState 依赖闭包捕获上一次的 memoizedState 值，useEffect/useCallback/useMemo 的 deps 机制通过重建闭包来更新捕获值，而 useRef 绕过闭包因 current 是可变引用。
为什么 useState 的初始值只在首次渲染生效
仔细想想，每次函数组件执行，整个函数体都会从头到尾重新运行一遍，useState 自然也会被反复调用。那么问题来了：为什么它不会每次都把状态重置回初始值呢？秘密就在于闭包捕获了上一次渲染时留下的 memoizedState 值。
React 内部为每个组件维护了一个 fiber 节点，并为其中的每个 hook 都关联了一个对象。这个对象里的 memoizedState 字段，就被当前 hook 函数形成的闭包所引用。等到下一次渲染，函数组件确实重新执行了，但这个闭包依然指向内存中同一个位置（由 React 内部的链表机制精准定位），因此它能顺利读取到上次保存下来的值。
- 试想一下，如果没有闭包，每次调用
useState都会重新走初始化逻辑，状态将永远停留在起点。 useState本身并不接受“key”这样的参数来标识自己，它依赖的是严格的调用顺序和链表位置的匹配。而闭包，正是确保每次都能拿到对应位置memoizedState的“粘合剂”。- 这也就解释了为什么 Hooks 必须写在函数顶层：一旦将它们放入条件判断或循环中，调用顺序就可能被打乱，闭包绑定的链表节点也就对不上号了。
useEffect 里读到旧 state 的本质是闭包“没更新”
我们常说的“闭包陷阱”，其本质是什么？其实是你期望闭包里的变量能跟随外部 state 的变化而同步更新，但实际上，这个闭包只在它被定义的那一刻捕获了一次变量的值。
举个典型的例子：你在 useEffect 的回调函数里使用了 count 这个状态，却没有把它放入依赖项（deps）数组。那么，这个回调函数闭包所捕获的，就是首次渲染时的 count 值。此后无论 count 如何更新，这个闭包都“看”不到。
- 依赖项数组的核心作用，就是给 React 一个明确的指令：“如果这里面任何一个值发生了变化，就请丢弃旧的闭包，基于最新的值重建一个新的闭包。”
- 传入空数组
[]意味着“永远使用首次创建的那个闭包”；传入[count]则表示“count变了就请更换闭包”；不传或者传入undefined/null，等同于要求“每次都换新的”。 - 所以，没有把
count加入 deps，并非 React “忘记”去更新，而是开发者主动选择了让 effect 一直沿用那个老的闭包。
useCallback/useMemo 的 deps 也是同一套闭包机制
这套机制并非 useEffect 独有。useCallback 返回的那个函数本身就是一个闭包；而 useMemo 所缓存的值，也完全依赖于其计算函数内部闭包所捕获的变量。
它们的依赖项对比逻辑与 useEffect 如出一辙：通过 Object.is 来严格比较前后两次渲染中 deps 数组的每一项是否相等。只要有一项不相等，React 就会丢弃旧的闭包，执行新的函数以生成一个全新的闭包。
- 漏写依赖项，会导致函数或计算值“卡在”旧的状态里。这并非 Bug，而是闭包在严格按规则工作。
- 过度填写依赖项（比如放入一个每次渲染都会新生成的对象），则会导致闭包频繁重建，完全失去了 memoization 的优化意义。
- 那么，为什么用
useRef可以存可变值、避免闭包“陷阱”呢？关键在于ref.current属性——它是一个可变的引用，其读写操作并不依赖于闭包的快照机制。
说到底，闭包并不是 React “引入”的一个需要解决的问题，它是 Ja vaScript 语言执行模型的自然产物。React Hooks 的所有设计，都是在理解和顺应这个模型的基础上，为其加上一套合理的约束规则。很多时候，我们以为自己是在“修复闭包问题”，实际上，我们是在学习如何与它和谐共处。
