【图】React源码解析-从底层数据结构、渲染调度到闭包原理深挖useRef的核心机制

这张图展示 useRef 在首次挂载（Mount）和后续更新（Update）时，如何操作 Fiber 节点上的 Hooks 链表。

📝 源码级深度解析（数据结构） ：

极简的数据结构 ：useRef 底层就是一个极简的普通 JavaScript 对象 { current: initialValue }。在源码中，mountRef 直接调用 mountWorkInProgressHook 获取 Hook 节点，并将这个对象赋值给 hook.memoizedState。
"永久性"引用 ：在 updateRef 阶段，React 完全跳过了重新创建对象的逻辑，直接返回已存在的 hook.memoizedState。这就是为什么在组件的无数次重新渲染中，useRef 返回的始终是同一个内存地址的对象。
与 useState 的本质区别 ：useState 的 memoizedState 存储的是具体的状态值 （如字符串、数字），且更新时会替换整个值；而 useRef 的 memoizedState 存储的是对象的引用 （指针），React 永远不会主动去修改这个对象的 current 属性。

这张图对比了修改 ref.current 与调用 setState 在调度器层面的根本差异。

📝 源码级深度解析（更新机制） ：

没有 updateQueue 的 Hook ：在 React 源码中，useRef 返回的 Hook 对象（hook）上存在 queue 属性，但它是空的（null）。这是因为 useRef 的更新不需要经过"协调（Reconcile）"流程，直接绕过 React 的响应式系统。
Mutation 直接作用于内存 ：当执行 ref.current = newValue 时，这仅仅是一次普通的内存赋值操作（JavaScript 对象属性修改）。React 的 Fiber 调度器（Scheduler）根本检测不到这个变化，因为对象的引用（内存地址）没有改变。
手动触发渲染才会更新视图 ：如果想在修改 ref 后让视图变化，必须额外调用 setState 或其他强制更新方法 。此时，虽然视图重新渲染了，但 useRef 拿到的依然是那个被修改过的对象，从而实现了"数据保留"的效果。

这张图展示了在异步操作（如 setTimeout、事件监听）中，useState 为何会捕获旧值，而 useRef 能读到最新值。

📝 源码级深度解析（闭包陷阱） ：

闭包（Closure）的本质 ：每次函数组件执行（渲染），都会生成一个全新的执行上下文 。useState 返回的 count 是一个基本类型值（或不可变引用） ，它被锁定在当前这次渲染的闭包中。当 setTimeout 读取它时，读到的是触发时的"快照"。
Ref 的"逃生舱"作用 ：useRef 返回的是一个可变对象（Mutable Object） 。由于组件每次渲染拿到的都是同一个对象的内存引用 ，因此异步回调通过 .current 读取到的值，永远是对象当前时刻的真实状态，绕过了闭包的捕获特性。
替代方案 ：React 官方推荐使用 useReducer 或 useCallback 配合依赖项来解决闭包陈旧问题，但 useRef 是最直接、最暴力的"绕过闭包"的方法（常用于存储定时器 ID、WebSocket 实例，或某些不需要触发渲染的"幕后"变量）。

这三张图从底层数据结构、渲染调度到闭包原理，完整覆盖了 useRef 的全部核心机制。