Ref 的固执与闭包的背叛：深入解析 Fiber 生命周期的内存布局

各位好，我是你们的 React 修仙导师。

今天我们不聊那些花里胡哨的 UI 渲染，不聊组件树的调和算法，我们要聊点“硬核”的，甚至有点“背德”的话题。我们要聊聊 React 里那个最神秘、最像“黑魔法”的 Hook —— useRef。

在很多人的眼里，useRef 就是个“不死身”。你往里面塞个对象，哪怕组件跑断腿、闭包把内存吃干抹净，只要组件还活着，那个 ref 对象的内存地址就是雷打不动的。它就像是那个混迹江湖多年的老油条，无论外面怎么洗牌，它永远坐在那个角落里，手里永远攥着它那杯没喝完的酒。

但是，真的这么简单吗？为什么有时候你会发现，你的 ref 对象明明还在，里面的 current 值却像是个“健忘症患者”？为什么闭包里捕获的 ref 看起来总是“老古董”？

今天，咱们就扒开 React 的裤裆，看看它的 Fiber 内部构造，聊聊 useRef 在内存里到底是怎么“苟”下来的。我们要搞清楚：那个引用唯一的 ref 对象，在 Fiber 的生命周期里，到底长什么样？

---

第一幕：闭包的牢笼与 Ref 的誓言

首先，咱们得明白 React 闭包是个什么鬼东西。

当你写一个函数组件：

function Counter() {
  const count = useState(0)[0];
  const increment = () => {
    setCount(c => c + 1);
  };

  useEffect(() => {
    // 这里的 count 闭包住了 0
    console.log(count); 
  }, []);

  return <button onClick={increment}>Count: {count}</button>;
}

在这个 useEffect 执行的时候，它捕获了一个 count 变量。这个 count 变量在那一刻是 0。哪怕你点了一万次按钮，count 变成了 10000，但这个 useEffect 里的闭包依然死死抱着 0 不放。这就是闭包的“背叛”。

这时候，useRef 出场了。它号称是“闭包的克星”。

function Counter() {
  const count = useState(0)[0];
  const ref = useRef(0);

  useEffect(() => {
    // 这里呢？ref.current 会不会也被闭包锁死？
    console.log(ref.current); 
  }, []);

  return <button onClick={() => { ref.current = count; setCount(c => c + 1); }}>Count: {count}</button>;
}

你可能会天真地以为，ref.current 也会被锁死，变成 0。但神奇的事情发生了：每次渲染，ref.current 都能拿到最新的值！

为什么？因为 useRef 返回的那个对象，它不是函数组件里的局部变量。它不依赖于函数的执行上下文。它就像是寄生在组件身上的一个寄生虫，或者是刻在组件灵魂里的一个图腾。

但是，这里有个巨大的误区。Ref 对象本身是不变的，但它的 current 属性指向的内容，可能会变。

如果 ref.current 指向一个基本类型数字，它是稳定的。如果 ref.current 指向一个对象 { a: 1 }，并且你执行了 ref.current = { a: 2 }，那么这个对象在内存里就被替换了！虽然 ref 这个盒子没换，但盒子里装的东西变了。这时候，如果你在闭包里抓着这个盒子的“旧内容”，你依然会看到旧东西。

这就是我们要探究的核心：那个“盒子”本身是怎么在 Fiber 生命周期的内存布局中保持唯一的？

---

第二幕：Fiber 节点——组件的“活体记忆体”

要搞懂 Ref 的内存布局，咱们得先认识 React 的“新宠”——Fiber。

以前 React 是递归渲染的，一旦卡住，页面就死机。现在有了 Fiber，React 就像是一个拥有精密大脑的木偶师。每一个组件实例，在 React 内部都有一个对应的 Fiber 节点。

你可以把 Fiber 节点想象成组件的“本体”。当组件渲染时，React 并不是在内存里重新堆砌一个组件，而是在内存里移动、更新这些 Fiber 节点。

每一个 Fiber 节点，都有一些核心属性，咱们重点看这几个：

class FiberNode {
  // 组件实例
  stateNode: any; 

  // 这是一个链表，用来存储 Hooks 的状态！
  // 重点来了，这里就是 Ref 的老家！
  memoizedState: null | FiberNode; 

  // ...
}

注意这个 memoizedState。它不是用来存 DOM 的，它是用来存 Hooks 状态 的。

React 的 Hooks 是一个链表结构。对于 Counter 组件，它的 memoizedState 链表大概长这样：

[ useRefNode(0), useStateNode(0), useStateNode(null) ]

第一个节点是 useRef，第二个是 useState，第三个是 useState。

所以，useRef 返回的那个对象，它的“本体”其实就是 FiberNode.memoizedState 链表的第一个节点！

这解释了为什么 Ref 是唯一的。因为每个 Fiber 节点（也就是每个组件实例）都有自己独立的 memoizedState。只要组件还挂在树上，这个 Fiber 节点就还在，这个链表就还在，链表头上的那个 Ref 对象引用就还在！

---

第三幕：内存布局的“特洛伊木马”

咱们来画个图（脑补一下），看看内存里到底发生了什么。

1. 堆内存：

   • 有一个巨大的对象，我们叫它 FiberNode。
   • 在 FiberNode 里面，有一个指针 memoizedState。
   • memoizedState 指向另一个对象 RefObject。
   • RefObject 里面有一个属性 current，它指向你传进去的初始值（比如数字 0）。

2. 栈内存（闭包环境）：

   • 函数组件执行，创建了 count 变量。
   • 函数组件执行，调用了 useRef，useRef 内部找到了当前 Fiber 节点的 memoizedState，把它包装了一下，返回给你。
   • 你的代码里有一个变量 const ref = ...，它只是拿到了 RefObject 的引用。

关键点来了：

当你组件重新渲染时，React 会创建一个全新的函数组件执行上下文（栈帧）。在这个新的栈帧里，const ref = ... 这行代码又执行了一遍。

按理说，每次执行这行代码，都应该返回一个新的 ref 对象吧？如果是这样，闭包里的 ref 就该变。

但是，React 的 useRef 实现机制极其狡猾。它不会每次都创建新对象。它会检查当前正在构建的 Fiber 节点（也就是 workInProgress Fiber）的 memoizedState。

• 如果 memoizedState 已经存在（组件已经挂载过），它就直接返回那个老对象。
• 如果 memoizedState 是 null（组件首次挂载），它才去创建一个新的 RefObject，塞进链表头，然后返回。

所以，在组件的整个生命周期内，useRef 返回的对象引用，确实是唯一的，因为它直接来源于 Fiber 节点的属性。

---

第四幕：生命周期——从“出生”到“死亡”

咱们来模拟一下这个 ref 对象的完整一生。

1. 挂载阶段：Ref 的诞生

function MyComponent() {
  const myRef = useRef(null);
  return <div ref={myRef}>Hello</div>;
}

• React 内部动作：
  1. 创建 FiberNode（组件实例）。
  2. 初始化 memoizedState 为 null。
  3. 遇到 useRef(null)。React 创建一个 RefObject，里面 current 是 null。
  4. 把这个 RefObject 插入到 memoizedState 链表头部。
  5. 把 RefObject 返回给组件。
  6. 遇到 <div ref={myRef}>。React 把 myRef（也就是那个 RefObject）赋值给 DOM 节点的 ref 属性。
  7. DOM 节点挂载。

此时，myRef 对象在堆内存里有一个确定的地址（比如 0x1234）。Fiber 节点持有这个地址的引用。DOM 节点也持有这个地址的引用。

2. 更新阶段：双缓冲与引用的稳定

这是最精彩的部分。假设你点击了按钮，组件需要更新。

• React 内部动作：
  1. React 并没有销毁旧的 FiberNode（除非你要卸载组件）。
  2. React 创建了一个新的 WorkInProgressFiberNode（正在构建中的新节点）。
  3. React 把旧节点的 memoizedState 复制给新节点。注意，这里复制的不是值，而是引用！
  4. 组件函数重新执行，const myRef = useRef(null) 再次被调用。
  5. useRef 发现新节点的 memoizedState 已经有了（就是刚才复制的那个），于是它直接返回那个老对象。

结果： 你的组件虽然重新渲染了，但 myRef 变量指向的内存地址依然是 0x1234！这就是所谓的“引用唯一性”。

3. 修改 Ref 的值

现在，你在这个组件里做了一件危险的事：

function MyComponent() {
  const myRef = useRef(0);

  useEffect(() => {
    // 闭包捕获了 myRef，但 myRef 指向的对象没变
    console.log(myRef.current); 
  }, []);

  const handleClick = () => {
    // 这里修改了 current
    myRef.current = 100;
  };

  return <button onClick={handleClick}>Update</button>;
}

• 内存变化：
  • myRef 对象本身（地址 0x1234）没变。
  • myRef.current 的值从 0 变成了 100。
  • useEffect 里的闭包里，虽然 myRef 变量本身没变（它还是指向 0x1234），但 0x1234 里的 current 已经是 100 了。所以 console.log 会打印 100。

这说明了什么？ 这说明 useRef 确实避开了闭包的陷阱，因为它返回的是外部持久化的对象引用。

4. 闭包陷阱的真正面目

等等，如果你这么做呢？

function MyComponent() {
  const myRef = useRef({ count: 0 });

  useEffect(() => {
    // 闭包捕获了 myRef
    console.log(myRef.current.count); 
  }, []);

  const handleClick = () => {
    // 你修改了 current 指向的对象内容
    myRef.current.count = 1;
    // 或者你替换了整个对象
    myRef.current = { count: 2 }; 
  };

  return <button onClick={handleClick}>Update</button>;
}

• 情况 A： myRef.current.count = 1。闭包里的 myRef.current.count 也会变成 1。因为 myRef 对象没变，只是属性变了。
• 情况 B： myRef.current = { count: 2 }。这里出事了！
  • 你把 myRef.current 指向了一个新对象（地址 0x5678）。
  • myRef 对象本身（地址 0x1234）依然没变。
  • 但是，闭包里捕获的 myRef 依然指向 0x1234。
  • console.log(myRef.current.count) 会打印 undefined（或者旧值），因为 0x1234 里的 current 指向的是 0x5678。

这就是闭包陷阱的本质： useRef 的引用是稳定的，但它的 current 内容可以是随时替换的。如果你在闭包里只依赖 ref.current，并且 ref.current 是引用类型，你需要小心它被替换了。

---

第五幕：DOM Ref 的特殊“羁绊”

除了存储数据，useRef 最常用的场景是获取 DOM。

function InputComponent() {
  const inputRef = useRef<HTMLInputElement>(null);

  useEffect(() => {
    if (inputRef.current) {
      inputRef.current.focus();
      console.log(inputRef.current.value);
    }
  }, []);

  return <input ref={inputRef} type="text" />;
}

这里有一个非常隐秘的内存绑定。

当组件挂载时，DOM 节点被创建。React 把这个 DOM 节点的引用（DOM Node 的内存地址）赋值给了 inputRef.current。

这意味着什么？ 意味着只要组件不卸载，inputRef.current 就一直死死地抓着那个 DOM 节点不放！

哪怕你把组件里的所有变量都清空了，哪怕你把组件的状态都重置了，只要组件还在 Fiber 树上，这个 inputRef 就能穿透一切，找到它的 DOM 爹。

这就是为什么在 useLayoutEffect 里操作 DOM 是安全的，也是为什么在 useEffect 里操作 DOM 可能会有时序问题（因为 DOM 已经渲染完了，但闭包可能还是旧的）。

但是，如果组件卸载了呢？

当组件卸载时，Fiber 节点被移除。memoizedState 里的 RefObject 也会随之被 GC（垃圾回收）回收。inputRef.current 就变成了 null。这就像是孩子死了，爹也疯了，手里抓着一把空气。

---

第六幕：实战演练——如何“驯服” Ref

让我们通过几个代码片段，来巩固一下刚才学到的内存布局知识。

场景 1：跨渲染周期的计数器

我们要实现一个功能：组件第一次渲染时记录一下数值，第二次渲染时读取一下这个数值。

function Example() {
  const prevCountRef = useRef<number>(0);

  const [count, setCount] = useState(0);

  useEffect(() => {
    // 这里读取 prevCountRef.current，它永远是最新的值
    // 因为 prevCountRef 是 Fiber 节点上的引用
    console.log(`Previous render count was: ${prevCountRef.current}`);

    // 每次渲染完，更新一下 prevCountRef，供下一次渲染使用
    prevCountRef.current = count;
  }, [count]);

  return (
    <div>
      <p>Current count: {count}</p>
      <button onClick={() => setCount(c => c + 1)}>Increment</button>
    </div>
  );
}

深度解析：
这里 prevCountRef 是一个普通的对象 { current: 0 }。
第一次渲染：prevCountRef.current 是 0。useEffect 执行，打印 0，然后更新为 1。
第二次渲染：prevCountRef 对象还是那个对象（地址不变）。useEffect 执行，打印 1（因为 prevCountRef.current 已经被更新了），然后更新为 2。
这个逻辑完全依赖 useRef 的引用稳定性。

场景 2：保存一个“脏”的值

有时候我们需要在组件里存一个状态，但不想触发重新渲染。

function ToggleButton() {
  const [isOn, setIsOn] = useState(false);

  // 这个 ref 里的值变了，React 不会重新渲染组件
  const toggleCountRef = useRef(0);

  const handleClick = () => {
    setIsOn(!isOn);
    // 更新 ref
    toggleCountRef.current += 1;
    console.log("Internal toggle count:", toggleCountRef.current);
  };

  return (
    <button onClick={handleClick}>
      {isOn ? "ON" : "OFF"}
    </button>
  );
}

深度解析：
注意 toggleCountRef.current 的变化不会导致组件重新渲染。这是因为它不在 memoizedState 链表里（等等，不对，它就在链表里）。

纠正： 它确实在 memoizedState 链表里。React 渲染的时候，会读取 memoizedState 来更新组件。但是，如果你在 useEffect 或者事件处理函数里修改了 ref.current，React 的渲染调度器并不知道这个变化。

为什么？因为 React 的渲染逻辑是：读取 memoizedState -> 更新 UI -> 重新执行组件函数 -> useRef 返回旧对象 -> 更新 memoizedState。
关键在于： useRef 返回的是旧对象，所以组件函数内部看到的 ref 没变。所以 ref.current 的变化不会触发重渲染。这就像是你口袋里的钱包（Ref）里钱变多了，但你的脸（UI）没变，因为没人看你的钱包。

场景 3：Ref 与闭包的“爱恨情仇”

这是最容易踩坑的地方。

function Form() {
  const [text, setText] = useState("");
  const inputRef = useRef<HTMLInputElement>(null);

  // 场景：我想在输入框聚焦的时候，打印一下当前的值
  useEffect(() => {
    const node = inputRef.current;
    if (!node) return;

    const handleFocus = () => {
      // 这里有个陷阱：如果 text 在闭包外面定义了，可能会被捕获
      // 但在这里，text 是局部变量，每次渲染都会变
      console.log("Focused value:", node.value);
    };

    node.addEventListener("focus", handleFocus);

    return () => {
      node.removeEventListener("focus", handleFocus);
    };
  }, []); // 空依赖数组

  return <input ref={inputRef} value={text} onChange={e => setText(e.target.value)} />;
}

在这个例子中，handleFocus 是一个闭包函数。每次 Form 组件重新渲染，handleFocus 函数体都会重新创建。
但是！inputRef.current 永远指向那个 DOM 节点。
所以，当你点击输入框时，handleFocus 执行，node.value 总是能拿到最新的输入框值。这就是 useRef 的魅力。

---

第七幕：进阶——Fiber 双缓冲与 Ref 的“重生”

为了彻底讲透，咱们得聊聊 React 的双缓冲机制。这能帮你理解为什么 useRef 在 Diff 算法里如此重要。

React 在渲染时，会维护两棵树：

1. Current Tree（当前树）： 展示给用户看的。
2. WorkInProgress Tree（工作树）： 正在构建的树，准备用来替换 Current Tree。

当渲染完成后，React 会瞬间把 WorkInProgress 树变成 Current 树。这个过程叫 commit。

在这个过程中，Fiber 节点是怎么处理的？
对于 useRef，如果节点类型没变，React 会复用 WorkInProgress 节点里的 memoizedState。

这意味着什么？
这意味着，即使组件重新渲染了，useRef 返回的那个对象的内存地址，在 commit 阶段之后，依然和之前一模一样！

除非组件卸载，或者你显式地替换了 ref.current，否则那个 ref 对象就像是个幽灵，一直潜伏在 Fiber 节点的内存里，等着你召唤。

---

第八幕：Ref 的“黑魔法”——DOM 与内存的桥梁

咱们最后来聊聊 forwardRef 和 useImperativeHandle。这两个东西让 ref 的用法变得极其复杂，也极其强大。

function FancyButton() {
  const buttonRef = useRef<HTMLButtonElement>(null);
  const [isHovered, setIsHovered] = useState(false);

  const handleHover = () => setIsHovered(true);
  const handleLeave = () => setIsHovered(false);

  return (
    <button 
      ref={buttonRef} 
      onMouseEnter={handleHover}
      onMouseLeave={handleLeave}
    >
      {isHovered ? "Hovered!" : "Hover me"}
    </button>
  );
}

// 父组件
function Parent() {
  const buttonRef = useRef<FancyButton>(null);

  const focusButton = () => {
    // 如果没有 useImperativeHandle，这里拿到的 buttonRef.current 是 FancyButton 组件实例
    // 而不是 DOM 元素！
    console.log(buttonRef.current);
  };

  return (
    <div>
      <FancyButton ref={buttonRef} />
      <button onClick={focusButton}>Focus</button>
    </div>
  );
}

在这个例子里，buttonRef.current 是 FancyButton 组件的实例（Fiber 节点的 stateNode 属性）。

如果你想在父组件里直接操作 DOM，你需要用到 useImperativeHandle：

function FancyButton() {
  const buttonRef = useRef<HTMLButtonElement>(null);

  // 暴露给父组件的接口
  useImperativeHandle(ref, () => ({
    focus: () => buttonRef.current?.focus(),
    scrollIntoView: () => buttonRef.current?.scrollIntoView(),
  }));

  return <button ref={buttonRef}>Click me</button>;
}

深度解析：
这里 ref 传递了两层：

1. 父组件的 buttonRef -> 指向 FancyButton 组件实例。
2. FancyButton 组件内部的 buttonRef -> 指向 DOM 节点。

useImperativeHandle 就像是一个翻译官，它把 FancyButton 组件实例（Fiber 节点）暴露给父组件，但只暴露了它想暴露的那几个方法（比如 focus）。

内存布局视角：

• 父组件的 buttonRef 指向 FancyButton 的 stateNode。
• FancyButton 的 stateNode 是一个 Fiber 节点。
• FancyButton 的 memoizedState 里存着 buttonRef 对象。
• buttonRef.current 指向 DOM 节点。

这就像是一个俄罗斯套娃，一层套一层。useRef 就像是那个最外层的钥匙，它保证了无论你套了多少层，只要钥匙（Ref 对象）还在，你就能打开盒子。

---

第九幕：总结——Ref 的“道”

好了，咱们今天把 useRef 从里到外翻了个底朝天。

1. Ref 是谁？ 它是 Fiber 节点 memoizedState 链表里的一个节点。它是组件的私有记忆体。
2. 为什么引用唯一？ 因为它在 Fiber 节点属性里，只要 Fiber 节点不销毁，它就不销毁。每次渲染，useRef 都会返回同一个对象引用。
3. 为什么闭包拿不到最新值？ 除非你把 ref.current 指向了新对象。Ref 对象本身是稳定的，但它的 current 内容是随时可变的。
4. DOM Ref 是什么？ 是一个指向真实 DOM 节点的指针。它让 React 的虚拟 DOM 和真实 DOM 建立了物理连接。

给你的建议：

• 用 Ref 存不需要渲染的数据： 计数器、定时器 ID、DOM 节点、全局变量。
• 警惕 Ref 的引用类型赋值： 尽量修改 ref.current 的属性，而不是替换整个对象，否则闭包会失效。
• 理解 Fiber： 搞懂了 Fiber 的内存布局，你就懂了 React 的所有 Hooks 的底层逻辑。useState 其实也是 useRef 加上 memoizedState 链表操作而已。

记住，useRef 是 React 给你的一把“后门钥匙”。它允许你绕过 React 的渲染机制，直接操作内存和 DOM。这把钥匙很锋利，用不好会伤到自己，但用好了，你就是那个掌控全局的架构师。

今天的讲座就到这里。希望大家以后看到 useRef，不再觉得它是个简单的 null，而是能看到它背后那根连接 Fiber 节点和堆内存的隐形线。祝大家编码愉快，内存管理得当！