React useRef 机制：为什么 ref.current 的修改不会触发组件重渲染？它在 Fiber 节点中是如何存储的？

React Refs 深度解析为什么你的组件像个“哑巴”而 Ref 却是个“忍者”大家好欢迎来到今天的 React 内部机制深度解剖课。我是你们的老朋友那个总是试图在代码里找 Bug 的“资深专家”。今天我们不聊业务逻辑不聊组件拆分我们要聊聊 React 里最神秘、最像“黑魔法”的 Hook ——useRef。你是不是经常遇到这种情况你想要一个变量它得记着上次的状态但是你又不希望它让 React 疯了一样地重新渲染整个屏幕于是你祭出了useRef。然后你发现你修改了ref.currentUI 却纹丝不动。你挠了挠头心想“这玩意儿是不是坏了”不它没坏它只是个“哑巴”。而useState才是个“话痨”。今天我们就来扒开 React 的裤裆比喻看看useRef到底藏在哪里为什么它修改了数据却像没修改一样以及它在 Fiber 节点里到底长什么样。第一章State vs Ref —— 婚姻的隐喻在讲 Fiber 之前我们得先搞清楚这两个家伙的关系。这就像婚姻。useState是个多愁善感的妻子。当你修改它的值时你得告诉她。她一听到消息就会哭天抢地大喊大叫触发重渲染要求全家组件重新装修一下房子渲染 UI。她非常敏感非常在乎外界的反馈。useRef是个冷血的室友。你修改它的值就像你悄悄把室友床底下的可乐换成了牛奶室友根本不知道也不会大惊小怪。你甚至可以在室友睡觉的时候组件渲染的时候偷偷摸摸地改它室友醒来组件重渲染的时候完全不知道刚才发生了什么。所以核心问题来了为什么ref.current 新值不会触发重渲染因为 React 的调度器压根没收到ref变化的通知。ref变化只影响内存里的一个对象不影响 React 需要渲染的“虚拟 DOM 树”。第二章Fiber 节点 —— React 的神经中枢要理解 Ref 的存储我们必须先理解Fiber。你可以把 Fiber 看作 React 的“神经细胞”。每一个组件在 React 内部都是一个FiberNode。它负责管理组件的生命周期、任务调度和状态。让我们来看看这个FiberNode类到底长什么样为了方便理解我简化了部分属性但保留了核心// 模拟 React FiberNode 的核心结构 class FiberNode { // 组件类型 type: any; // 当前组件的 props pendingProps: any; // 更新后的 props用于渲染 memoizedProps: any; // 状态管理这里是关键 memoizedState: any; // 对于 State它是队列对于 Ref它是个对象。 // alternate这是 React 的秘密武器用于并发渲染 alternate: FiberNode | null; // ... 其他属性tag, effectTag, child, sibling, return... }注意看memoizedState。这个属性是所有 Hooks 的家。如果是useState这里存的是queue更新队列。如果是useRef这里存的是一个RefObject。第三章Ref 在 Fiber 里是长什么样的当你在组件里写const myRef useRef(null)时React 做了什么React 会调用mountRef函数。这个函数会创建一个{ current: null }的普通对象。然后这个对象会被塞进当前 Fiber 节点的memoizedState里。代码模拟function mountRef(initialValue) { // 1. 创建一个 Ref 对象 const refObj { current: initialValue }; // 2. 创建一个 Hook 对象用来占位 // 注意这里用 effectTag 里的特殊标记来区分是 ref 还是 state const hook { memoizedState: refObj, // 核心Ref 对象被挂载到了 memoizedState 上 }; // 3. 把这个 hook 放到链表里 // ...省略 hook 链表操作代码... return refObj; }图解存储结构想象一下你的组件树是这样的App (Fiber A)-Header (Fiber B)-Footer (Fiber C)Fiber A (App):memoizedState-[hookState1, hookRef1]Fiber B (Header):memoizedState-[hookRef2]Fiber C (Footer):memoizedState-[hookState2, hookRef3]这里有个坑每个 Fiber 节点都有自己的memoizedState。这意味着如果你在App里用useRef在Header里也用useRef它们是完全独立的。App 的 Ref 变了不会影响 Header 的 Ref。它们就像住在不同楼层的室友互不干扰。第四章为什么修改 Ref 不会重渲染核心机制现在让我们来看看ref.current 123到底发生了什么。为什么 React 就像瞎了一样1. State 的更新流程对比组当你写setState(123)时React 调用dispatchSetState。React 把这个更新推入fiber.memoizedState里的queue。React 调用scheduleUpdateOnFiber告诉调度器“嘿有个活儿要干”调度器开始工作进入render阶段生成新的 Fiber 树然后进入commit阶段把新的 DOM 扔到屏幕上。结果组件重渲染。2. Ref 的更新流程主角当你写ref.current 123时React 调用dispatchRef或者更底层的逻辑。关键点来了dispatchRef拿到当前的 Fiber 节点。它直接修改了fiber.memoizedState.current的值。它没有调用scheduleUpdateOnFiber它没有生成新的 Fiber 树它没有执行render函数结论因为 Ref 的更新不经过调度器不经过render阶段直接在内存里改了值。所以组件根本不知道自己变了UI 自然不会重绘。第五章Fiber 的“克隆”机制与 Alternate讲到这里你可能会有个疑问既然 Ref 不触发重渲染那我在useEffect里改 Ref然后依赖数组里写了 RefuseEffect会执行吗答案是会执行。这就涉及到 React 更新周期里的另一个概念Alternate Fiber双缓冲。当 React 开始处理一个组件的更新时它不会直接在“当前 Fiber”上改。它会先克隆一个“工作 Fiber”。// 模拟更新过程 function updateFunctionComponent(fiber) { // 1. 克隆当前的 Fiber 节点创建一个 workInProgress 节点 const workInProgress fiber.alternate || createFiber(fiber); // 2. 把当前 Fiber 指向 workInProgress fiber.alternate workInProgress; workInProgress.alternate fiber; // 3. 开始渲染逻辑 const children fiber.type(fiber.pendingProps); // 4. 同步 Ref // 注意这里同步的是 workInProgress 的 ref而不是当前 fiber 的 ref syncRef(workInProgress, fiber); }这里的syncRef是什么这是 React 内部的一个函数它负责把“当前 Fiber”的 Ref 同步到“工作 Fiber”上。为什么这么做因为useEffect的依赖数组检测的是workInProgress的 Ref 状态而不是currentFiber 的状态。虽然对外界开发者来说Ref 是同一个对象但在 React 内部为了并发渲染的稳定性它维护了两份引用。代码示例// 模拟 React 内部 syncRef 的逻辑 function syncRef(workInProgress, current) { // 如果 workInProgress 有 ref就把 current 的 ref.current 复制过来 if (workInProgress.ref ! null) { // 注意这里的逻辑比这复杂涉及到 ref 的创建和销毁 // 但核心思想是Ref 的值被同步到了新的 Fiber 节点上 const currentRef current.memoizedState?.current; if (currentRef) { workInProgress.memoizedState { current: currentRef }; } } }所以当你修改ref.current时当前 Fiber的memoizedState.current变了。工作 Fiber的memoizedState.current也会在渲染过程中被同步更新。结果useEffect发现依赖变了于是触发回调。第六章实战演练 —— Ref 的那些事儿光说不练假把式。我们来写几个代码场景看看 Ref 在 Fiber 里是如何操作的。场景 1聚焦输入框这是 Ref 最经典的用途。我们不想让用户输入时屏幕闪烁只想在组件挂载后让输入框自动获得焦点。function FocusInput() { const inputRef useRef(null); useEffect(() { // 这里 inputRef.current 指向真实的 DOM 节点 if (inputRef.current) { inputRef.current.focus(); } }, []); return input ref{inputRef} typetext /; }Fiber 里的过程mountRef创建{ current: null }。组件渲染React 创建input节点。React 发现refprop把 DOM 节点赋值给inputRef.current。useEffect执行调用 DOM API。关键这个过程没有任何 State 更新所以没有重渲染。场景 2存储状态有时候你需要一个变量它得跨渲染周期存在但不能触发重渲染。比如一个计时器或者一个复杂的对象缓存。function Timer() { const timerRef useRef(null); const start () { if (timerRef.current) return; // 防止重复点击 timerRef.current setInterval(() { console.log(Tick Tock...); // 这里我们修改了 ref.current // 但是组件不会重渲染console.log 也不会被 React 拦截 }, 1000); }; return button onClick{start}Start/button; }场景 3Ref 里的 State大坑这是新手最容易犯的错。如果你在 Ref 里存了一个对象并且修改了这个对象的属性这个变化不会触发重渲染。function Counter() { const [count, setCount] useState(0); // 错误示范试图在 ref 里存 state const stateRef useRef({ count }); useEffect(() { // 当 count 变化时这里不会更新 // 因为 stateRef.current.count 永远是初始值 console.log(stateRef.current.count); }, [count]); return button onClick{() setCount(count 1)}Count: {count}/button; }为什么因为useEffect的依赖数组里是count而count是从useState来的。useEffect只在count变化时运行。此时React 会把count的值传进去但stateRef本身并没有变它指向的内存地址没变。第七章Fiber 节点的内存布局深度剖析让我们再深入一点看看memoizedState在 Fiber 节点里到底是个什么结构。在 React 源码中memoizedState实际上是一个链表。FiberNode └── memoizedState: { next: { ... }, // 下一个 Hook memoizedState: { current: value } // 当前 Hook 的值 }State Hook:memoizedState存储的是updateQueue对象。Ref Hook:memoizedState存储的是{ current: value }对象。当你执行ref.current newValue时实际上就是修改了这个{ current: value }对象的.current属性。// 源码级别的伪代码 function dispatchRef(fiber, newRefValue) { // 1. 找到当前的 ref hook const hook fiber.memoizedState; // 2. 直接修改 current 属性 hook.memoizedState.current newRefValue; // 3. 注意这里没有调用 scheduleUpdateOnFiber(fiber); // 也没有调用 enqueueUpdate(hook, ...); }这就好比你在图书馆看书React 渲染你用笔在书页上划了个重点修改 Ref。你划了重点但你并没有告诉管理员“这本书更新了”管理员不会重新发新书给你你继续看你的书就行。第八章Ref 的“副作用”属性在 Fiber 节点中Ref 还有一个隐藏的属性ref注意不要和refprop 混淆这里指 FiberNode 的属性。FiberNode 有一个ref属性它通常为null除非你在 FiberNode 上挂载了特殊的 ref。但是当你在 JSX 里写div ref{myRef}时React 会把这个 ref 函数或对象挂载到对应的 DOM Fiber 节点上。// React 处理 ref prop 的伪代码 function reconcileChildren(currentFiber, workInProgressFiber) { // 假设我们正在处理一个 div const domFiber createFiber(workInProgressFiber.type); // 如果有 ref prop if (workInProgressFiber.ref ! null) { // 把 ref 保存到 domFiber 的 ref 属性上 domFiber.ref workInProgressFiber.ref; } return domFiber; }作用这个ref属性在 React 渲染过程中会被使用。如果是functionref:ref(currentNode)。如果是objectref:ref.current currentNode。这是 Ref 与 DOM 建立连接的唯一桥梁。第九章useEffect 和 Ref 的爱恨情仇我们回到之前的问题为什么useEffect能感知到 Ref 的变化因为useEffect的执行依赖于依赖数组。当组件更新时比如点击按钮React 会计算新的依赖数组。function MyComponent() { const [count, setCount] useState(0); const myRef useRef(0); useEffect(() { // 依赖数组[count, myRef] console.log(count, myRef.current); }, [count, myRef]); return button onClick{() setCount(count 1)}Count/button; }这里有个巨大的陷阱如果你在依赖数组里写了myRefReact 会怎么比较它React 会比较currentFiber.memoizedState.current和workInProgressFiber.memoizedState.current的值。但是这里的比较是浅比较。// 如果 myRef.current 是一个对象 const objRef useRef({ a: 1 }); useEffect(() { console.log(Effect runs); }, [objRef]); // 错误永远只会在第一次运行原因objRef对象的引用地址在组件生命周期内是不变的虽然objRef.current.a变了但objRef这个变量本身指向的内存地址没变。所以React 认为依赖没变useEffect不会执行。正确的做法要么依赖count在useEffect里读objRef.current.a。要么使用useRef的特殊技巧比如在useEffect里修改 ref或者用useLayoutEffect配合ref的变化但通常建议不要把 ref 放在 useEffect 依赖数组里除非你明确知道你在做什么。第十章总结与灵魂拷问好了家人们我们终于讲完了useRef的底层机制。让我们回顾一下核心要点存储位置Ref 存储在FiberNode.memoizedState中具体是一个{ current: value }对象。不触发渲染修改ref.current不会调用scheduleUpdateOnFiber不经过渲染管道只修改内存数据。Fiber 链表每个 Fiber 节点维护自己的 Ref 链表互不干扰。双缓冲机制在更新过程中Ref 的值会被同步到workInProgressFiber 节点上这保证了useEffect能感知到变化前提是依赖数组正确。Ref vs StateState 是给 UI 用的Ref 是给 JS 逻辑用的DOM 访问、计时器、存储缓存。最后送给大家几个面试题也是坑Q:在useEffect里修改ref.current然后在下一次useEffect里读ref.current需要把ref加到依赖数组吗A:不需要因为ref对象本身不会变只有它指向的值会变。依赖数组里放ref是无效的除非你每次都重新创建 ref 对象那是另一种用法。Q:为什么不能用 Ref 存 StateA:因为 Ref 不触发重渲染。如果你在 Ref 里存了一个对象修改了对象属性UI 不会变你也无法通过 UI 反馈来更新 Ref。State 和 UI 是强绑定的Ref 和 UI 是解绑的。Q:useRef和createRef有什么区别A:createRef只能用在类组件里或者函数组件里手动传递。useRef是 Hook每次渲染都会返回同一个 ref 对象除了初始挂载时。如果你在循环里用useRef一定要用useCallback包裹或者用useRef(prev prev)的技巧否则会导致 ref 指向最后一个元素。讲师结语React 的 Ref 机制就像是一个没有监听器的变量。它安静、隐秘直接操作 DOM 或内存。它不参与 React 的“渲染派对”所以它永远不会让派对变得混乱。希望这篇长文能让你对 React 的 Fiber 架构有更深的理解。记住理解了 Fiber你就理解了 React 的“心”。下次当你修改ref.current却发现 UI 没变时别慌那是 React 在对你眨眼呢。下课如果有问题我们在评论区虽然这里没有评论区继续探讨