React 热更新原理（React Refresh）：在代码替换时，它是如何通过映射旧 Fiber 状态到新组件实现的？

嘿，各位前端界的“代码艺术家”们，大家好！

今天咱们不聊那些虚头巴脑的架构设计，也不搞什么企业级应用的落地指南。咱们要聊的是个“玄学”问题——当你手指放在键盘上，敲下一个 Ctrl+S，那一瞬间，浏览器里的页面是怎么“变魔术”的？

你有没有想过，为什么我修改了一个变量名，或者给组件加了个 console.log，页面上的数据却像是有记忆一样，稳稳地待在那里，没有重置成初始值？

这就是我们要聊的主角——React Refresh。它就像是一个隐形的快递员，在你的代码和浏览器之间传递着“记忆”。

今天，我就要带大家扒开 React Refresh 的裤衩子，看看它是如何在这个看似混乱的模块化世界里，把你的旧 Fiber 状态，精准地塞进新组件的嘴里。

准备好了吗？让我们开始这场关于“代码复活”的技术探险。

---

第一部分：HMR 的前世今生——从“重写”到“映射”

在 React Refresh 出现之前，我们玩热更新（HMR）就像是在玩俄罗斯方块，你试图在不破坏整个堆栈的情况下塞入一个新的方块。那时候最流行的库是 react-hot-loader。

react-hot-loader 是个狠角色，它干了什么？它重写了你的代码！它拦截你的组件，在运行时把你的代码“剪切、粘贴”到浏览器里。这就像是把你的房子拆了，把砖头运过来，然后重新砌起来。

这有什么问题？
问题大了去了。因为它是重写，所以你的 this 指向会乱，你的类组件的静态方法会丢，你的 useEffect 的清理函数会执行两次，甚至有时候会直接把浏览器搞崩，弹出一个红色的报错框：“Unexpected token”。

React Refresh 感到很羞愧。于是，React 团队决定换一种打法。

他们决定：我不重写你的代码，我只做“翻译”和“搬运”。

这就是 React Refresh 的核心哲学：符号化执行。

想象一下，你的模块就像是一个个独立的房间。当 main.js 需要更新时，React Refresh 会检查哪些房间被修改了。它不会冲进去把房间拆了，而是会敲门，递给你一张“旧状态地图”，然后让你拿着地图去填新房间的空缺。

---

第二部分：模块的身份证——Symbol.for("react-refresh")

React Refresh 是怎么知道哪个模块变了呢？它又怎么知道哪个模块是旧的呢？

这就需要用到 JavaScript 的一个冷门 API：Symbol。

在 React Refresh 的世界里，每个模块都有一个特殊的身份证。当浏览器加载模块时，React Refresh 会给这个模块挂载一个特殊的属性：

// 在浏览器运行时，React Refresh 注入的代码大致如下
const module = {
  id: 12345, // 这只是普通的模块 ID
  // 关键来了！
  [Symbol.for("react-refresh/runtime")]: {
    needsRefresh: true,
    signature: "function Counter() { ... }" // 这里存着组件的签名
  }
};

这个 Symbol.for("react-refresh/runtime") 就是钥匙。React Refresh 的运行时就像个保安，拿着这把钥匙在检查每一个进出的模块。

当你保存文件时，Webpack（或者 Vite）会重新编译模块。新的模块带着新的 id 和新的代码回来了。React Refresh 发现：“咦？这个模块有钥匙，而且它的签名变了！”

这时候，React Refresh 就知道：嘿，老兄，你的代码变了，该换班了。

---

第三部分：快照——旧 Fiber 的遗书

现在，问题来了：旧组件的状态去哪儿了？

当你保存文件时，React 并没有销毁旧组件。相反，它把旧组件的状态“拍了一张照片”。这个过程叫做快照。

这个快照是在哪里生成的呢？是在 ReactDevTools 里。

当你点击浏览器右上角的“更新”按钮（或者当你修改代码并保存时），ReactDevTools 会接管一切。它会遍历整个 React 的 Fiber 树（这就是 React 的虚拟 DOM 树，每个节点都是一个 Fiber）。

它会走到每一个挂载的组件节点，把它的状态（memoizedState）、它的 refs、它的 key，全部提取出来。

这就好比你搬家了，你不能把家里的米缸（状态）扔了。React Refresh 会把米缸里的米装进一个个袋子，贴上标签，打包好。

代码示例：旧 Fiber 的结构

// 假设这是 React 内部的一个 Fiber 节点
const oldFiber = {
  type: CounterComponent, // 新的组件函数
  memoizedState: {        // 这是旧的状态，React Refresh 要把它存起来
    value: 5,             // 比如我们之前的 count 是 5
    next: {               // 链表结构，一个组件可能有多个 state
      value: 10,
      next: null
    }
  },
  memoizedProps: {        // 旧组件的 props
    color: "blue"
  }
};

React Refresh 会把这个 oldFiber 的 memoizedState 序列化成 JSON，或者某种可传输的格式，扔给 Webpack 的 HMR 插件。

---

第四部分：映射的艺术——从旧 Fiber 到新组件

这是最精彩的部分，也是你问题的核心：它是如何通过映射旧 Fiber 状态到新组件实现的？

流程是这样的：

1. 识别变更：Webpack 告诉 React Refresh：“模块 12345 更新了，请处理。”
2. 获取快照：React Refresh 找到旧模块的 Fiber 树，提取出状态。
3. 序列化传输：状态被打包，通过网络发送给浏览器。
4. 新模块加载：浏览器加载了新的 Counter 组件代码。
5. 注册符号：新组件一加载，就调用 ReactRefresh.register，把它的 Symbol 放进全局表里。
6. 接收快照：React Refresh 收到快照，发现这个快照对应的就是 Counter 这个 Symbol。
7. 注入状态：React Refresh 调用新组件的更新逻辑，把旧状态“喂”给新组件。

核心机制：ReactCurrentDispatcher

React 16 引入了 Dispatcher。你可以把它理解成是一个“状态分发器”。

// React 内部的大致逻辑（伪代码）
const ReactCurrentDispatcher = {
  current: null // 这个指针指向当前正在运行的组件使用的 Dispatcher
};

function renderWithHooks() {
  // 1. 创建一个新的 Dispatcher
  const dispatcher = createDispatcher(); 

  // 2. 把它赋值给全局指针
  ReactCurrentDispatcher.current = dispatcher;

  // 3. 执行组件函数
  const result = Component(props);

  // 4. 渲染结束，销毁（但在 React Refresh 下，我们会保留它）
  return result;
}

当 React Refresh 想要给新组件注入状态时，它不是直接去改新组件的变量。它必须通过 Dispatcher。

// React Refresh 的注入逻辑（极度简化版）
function injectState(oldFiber, newComponent) {
  // 1. 获取旧的状态链表
  const oldState = oldFiber.memoizedState;

  // 2. 创建一个新的 Dispatcher，并把旧状态填进去
  const newDispatcher = {
    useState: (initState) => {
      // 这里是关键！如果 React Refresh 给我们传了旧状态，我们就用旧的
      // 否则就用初始化值
      if (oldState) {
        const state = oldState.value;
        const setState = (newValue) => {
           // 更新逻辑... 这里简化了
        };
        // 返回一个“假”的 Hook 对象
        return [state, setState];
      }
      return [initState, () => {}];
    },
    // ... 其他 hooks
  };

  // 3. 把这个 Dispatcher 赋值给 ReactCurrentDispatcher
  ReactCurrentDispatcher.current = newDispatcher;

  // 4. 重新执行组件函数
  // 这时候，组件里的 useState() 调用，实际上是在调用我们注入的那个带状态的函数
  newComponent();
}

你看，这就是映射！我们并没有替换 newComponent 这个函数本身。我们替换的是 newComponent 运行时的“环境”。

当你在新组件里写：

function Counter() {
  const [count, setCount] = useState(0); // 这行代码执行了
  return <div>{count}</div>;
}

React Refresh 会拦截这行代码的执行。它知道：“哦，这是 useState”。于是它不执行 useState 的默认逻辑（initState），而是直接返回我们刚才注入的 count = 5。

所以，当你再次点击按钮时，setCount 修改的是同一个引用。页面不需要重新渲染整个树，只需要更新那个变了的数据。

---

第五部分：代码实战——一个状态迁移的完整演示

让我们来个具体的例子。假设我们有一个 useReducer 组件。

修改前的代码（旧代码）：

// counter.js
import React, { useReducer } from 'react';

// 旧的状态定义
const initialState = { count: 0 };

function reducer(state, action) {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 };
    default:
      return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);

  console.log('Rendering with count:', state.count);

  return (
    <div>
      <p>Count: {state.count}</p>
      <button onClick={() => dispatch({ type: 'increment' })}>
        Increment
      </button>
    </div>
  );
}

export default Counter;

场景：
你把 count 改成了 number，把 reducer 改成了 incrementByTwo。

修改后的代码（新代码）：

// counter.js (热更新后)
import React, { useReducer } from 'react';

// 新的状态定义
const initialState = { count: 0 };

// 新的 reducer
function reducer(state, action) {
  switch (action.type) {
    case 'increment':
      // 逻辑变了，现在每次加 2
      return { count: state.count + 2 };
    default:
      return state;
  }
}

function Counter() {
  // 变量名也变了，count -> number
  const [number, dispatch] = useReducer(reducer, initialState);

  console.log('Rendering with number:', number.count);

  return (
    <div>
      <p>Number: {number.count}</p>
      <button onClick={() => dispatch({ type: 'increment' })}>
        Increment
      </button>
    </div>
  );
}

export default Counter;

发生了什么？

1. WebPack 检测到 counter.js 变了。
2. React Refresh 拿着旧 Fiber 的数据（假设此时 count 是 10）。
3. 新代码加载。Counter 函数重新定义了。
4. 注入：React Refresh 创建一个新的 Dispatcher。
   • 它看到 useReducer。
   • 它把旧 Fiber 里的 state（即 { count: 10 }）注入给新的 reducer 的初始值。
   • 注意，reducer 函数体变了，但它接收的 state 对象还是那个 count: 10 的对象引用（或者深拷贝后的副本）。
5. 渲染：
   • 新的 reducer 执行。它接收到 state = { count: 10 }。
   • 它执行 return { count: state.count + 2 }。
   • 结果是 { count: 12 }。
   • React 认为状态变了，触发渲染，显示 12。

神奇吗？ 你不仅保留了状态（10变成了12），而且你甚至改了 reducer 的内部逻辑，甚至改了变量名。React Refresh 就像是一个不知疲倦的翻译官，确保新代码能听懂旧数据的语言。

---

第六部分：Ref 与 Effect 的“悲伤故事”

既然 React Refresh 这么强，是不是所有东西都能热更新？

当然不是。它也有它的局限性，这也是理解其原理的关键。

1. useRef 的困境

useRef 返回的是一个对象。在 React Refresh 中，如果对象结构变了，或者对象引用变了，它就很难映射。

比如，你把 ref = React.createRef() 改成了 ref = useRef(0)。

React Refresh 试图保留 ref.current 的值（比如 10），但是 ref 这个对象的引用变了。React Refresh 无法自动把旧对象的属性“克隆”到新对象上。

结果： ref.current 会被重置为 undefined（对于 createRef）或初始值（对于 useRef）。

2. useEffect 的死亡

useEffect 是生命周期钩子。当你修改代码时，React Refresh 会尝试调用 useEffect 的 cleanup 函数来销毁旧组件。

但是，如果你的代码结构变了（比如你把 useEffect 移到了另一个组件里，或者你修改了 useEffect 依赖项的逻辑），清理函数可能会找不到对应的组件实例。

结果： React Refresh 会报错，或者干脆放弃热更新，强制刷新整个页面。

3. 类组件的噩梦

React Refresh 对类组件的支持非常有限。因为类组件依赖于 this 的绑定。React Refresh 难以追踪 this 在代码重写过程中的变化。

结果： 类组件的热更新通常会失败，或者导致内存泄漏。

---

第七部分：DevTools 的角色——幕后黑手

如果 React Refresh 是一个魔术师，那么 React DevTools 就是那个拿着手电筒的观众。

React Refresh 严重依赖 window.__REACT_DEVTOOLS_GLOBAL_HOOK__。这个全局变量是 React 和 DevTools 之间的桥梁。

当你安装 React DevTools 扩展时，它会注入这个 Hook。

• 注册阶段：组件加载时，调用 hook.injectIntoDevTools()。
• 快照阶段：当你点击“更新”时，DevTools 调用 hook.checkForUpdates()。
• 映射阶段：DevTools 调用 hook.getFiberRoots() 获取所有根节点，遍历 Fiber 树，提取状态，然后通过 Webpack 的 HMR API 把状态传回给 React Refresh。

代码示例：DevTools 的注入逻辑

// React DevTools 里的代码
const hook = {
  injectIntoDevTools(params) {
    // 1. 拦截 React 的 render
    const oldRender = ReactRenderer.render;
    ReactRenderer.render = function(element) {
      // 2. 渲染前，检查是否有待注入的状态
      const injectedState = checkPendingUpdates(params); 

      if (injectedState) {
        // 3. 如果有，注入 Dispatcher
        ReactCurrentDispatcher.current = injectedState.dispatcher;
      }

      // 4. 执行渲染
      return oldRender.call(this, element);
    };
  },

  checkForUpdates(params) {
    // 这里就是魔法发生的地方
    // 遍历所有模块，检查 Symbol
    // 找到变更的模块
    // 序列化 Fiber 状态
    // 返回 { dispatcher: ..., component: ... }
  }
};

没有这个 Hook，React Refresh 就是一个瞎子，它不知道哪个模块变了，也不知道该把旧状态塞给谁。

---

第八部分：总结——映射的本质

好了，让我们回到最初的问题：它是如何通过映射旧 Fiber 状态到新组件实现的？

答案其实很简单，也很残酷。

React Refresh 并没有把“旧组件”变成“新组件”。它只是给“新组件”穿上了一件“旧组件的皮”。

它利用 Dispatcher 机制，在组件运行的那一刻，劫持了 useState 和 useReducer 的调用。它把旧 Fiber 树里的 memoizedState 读取出来，重新包装成一个假的 Hook 对象，然后塞进 ReactCurrentDispatcher.current。

当你的新组件函数执行时，它以为自己是在初始化状态，但实际上，它是在读取 React Refresh 预先准备好的“旧数据”。

这就好比：

• 旧组件 是一辆车。
• 新组件 是一辆新车。
• React Refresh 是一个技师。
• 旧 Fiber 状态 是车里的乘客。

当车（新组件）造好了，技师（React Refresh）没有把乘客扔出去。他只是把乘客重新安排到了新车（新组件）的座位上。

这就是映射的本质：引用的延续，而非实体的替换。

所以，下次当你修改代码，看着页面上的数据纹丝不动时，不要只觉得它是“React 的特性”。你要知道，在你的浏览器背后，有一整套精密的模块系统、符号机制、Dispatcher 拦截和 Fiber 遍历算法，正在为了保存你的数据而疯狂工作。

这很酷，不是吗？

好了，今天的讲座就到这里。如果你觉得这事儿有点意思，记得点赞，或者去试试修改你的 useRef 看看会发生什么。我们下期再见！