React 对抗注水瓶颈：分析 Selective Hydration 源码中针对用户点击位置优先注水的算法实现 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

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

今天我们不开会，不聊那些让人头秃的架构设计图，我们坐下来，剥开 React 那层闪闪发光的“Concurrent Mode”（并发模式）外衣，聊聊它那个让人爱恨交加的“强迫症”——Selective Hydration（选择性注水）。

如果你是一个资深 React 开发者，你一定经历过那种时刻：你满怀信心地开启了 SSR（服务端渲染），以为从此以后页面加载如丝般顺滑。结果呢？用户手速一快，点击了一个按钮，然后控制台就给你弹出一个红色的、令人心碎的报错：

Hydration failed because the initial HTML received from the server did not match the client side tree.

翻译成人话就是：“React 这家伙，发现你服务端生成的 HTML 和它客户端生成的树不一样，它崩溃了！”

这就像是你在餐厅点了一盘红烧肉（服务端 HTML），端上来一看，怎么是一盘凉拌木耳（客户端 React 渲染）？React 不干了，它是个完美主义者，它必须确保这两个版本一模一样。

但是，如果每次都要等整个页面都“完美匹配”了再展示，那用户体验就太差了。用户点击了按钮，你却还在服务端拿着放大镜对比整个 DOM 树？那用户手都要抖断了！

所以，React 18 引入了 Selective Hydration。简单来说，就是：别管整个世界了，用户现在正盯着哪里，我们就先注水哪里！

今天，我们就来像拆解炸弹一样，深入 React 源码，看看它是如何根据用户的点击位置，精准地找到“注水锚点”，然后“嗖”的一下把水注进去的。

第一部分：为什么 React 会“水土不服”？

在讲算法之前，我得先给你们泼盆冷水，讲讲这个“Hydration”（注水）到底是个什么鬼。

SSR 的流程是这样的：

服务端生成 HTML 字符串（比如 <div>Hello</div>）。
这个字符串直接扔给浏览器，浏览器立马渲染出来，用户看到的是文字。
React 客户端拿到这个 HTML，开始干活。它要把这个 HTML 和自己脑子里的 Fiber 树（React 的内部数据结构）做比对。
比对过程： React 检查 div 对不对？Hello 这个文本节点对不对？如果都对，它就“注水”成功；如果不对，它就抛错。

问题来了： 如果用户在页面加载的一瞬间，手速极快地点击了“提交”按钮。此时 React 还没来得及完成整个页面的比对，用户就触发了点击事件。React 一看：“哎？你这个 HTML 是我刚才生成的，但我还没验证完，你怎么敢点击？”

这时候，React 就会进入一种“恐慌模式”。它必须强制暂停所有操作，去完成全量 Hydration，然后才能处理你的点击。这就是传说中的 Hydration Mismatch。

Selective Hydration 的核心思想就是：别全量注水了！根据用户的行为（点击、输入），推测出用户想看哪里，然后只注水那一小块区域！

第二部分：算法的入口——捕获“罪魁祸首”

当用户点击屏幕上某个元素时，事件监听器会被触发。React 的核心算法从哪里开始？从 getEventTarget 开始。

这是 React 源码（在 ReactFiberHydrationComponent.js 或相关文件中）的一个关键入口点。它的任务很简单：把浏览器原生的事件对象，变成 React 能理解的“DOM 节点”。

为什么需要这一步？因为原生的事件对象里包含了一堆乱七八糟的信息（target, currentTarget, bubbles, etc.），React 需要拿到那个实实在在的 DOM 元素。

// 伪代码示例：React 源码中的 getEventTarget 逻辑
function getEventTarget(domEvent) {
  const target = domEvent.target;

  // 如果点击的是 window 或者 document，那我们没法注水，直接返回 null
  // 因为 window 和 document 是全局的，没有特定的子树需要注水
  if (target === window || target === document) {
    return null;
  }

  // 如果点击的是 window 或者 document 里的某个元素，比如 button
  // 我们就把这个元素拿回来
  // 注意：React 会做一些特殊处理，比如区分 SVG 和 HTML，但核心逻辑就是这一句
  return target;
}

好，现在 React 拿到了用户点击的那个 DOM 节点。假设用户点击了一个 <button id="submit">提交</button>。

接下来，React 需要回答一个哲学问题：“在这个节点周围，有没有一个‘锚点’（Anchoring Point）？这个锚点必须是 React 服务器端生成的 HTML 中已经存在的，并且是 React 可以验证的节点。”

这就是 Selective Hydration 的第一步：寻找锚点。

第三部分：寻找锚点——一场向上回溯的“爬山”游戏

如果用户点击了 <button>，React 怎么知道该注水哪里？

它不会傻乎乎地直接注水 <button>，因为 <button> 里面可能包含很多子元素，比如 <span>提交</span>，而这些子元素在服务端 HTML 里可能不存在。如果直接注水，又会导致 Mismatch。

React 的策略是：向上找！

它会在 DOM 树中，从用户点击的节点开始，一路 parentNode 向上回溯，直到找到一个“可注水节点”。

什么是“可注水节点”？
简单来说，就是那些在服务端 HTML 中有对应元素，并且在 React Fiber 树中有对应 Fiber 节点的节点。

让我们来看看源码中 getNearestHydratable 的实现逻辑。这可是 Selective Hydration 的灵魂所在。

// 伪代码示例：React 源码中的 getNearestHydratable 逻辑
function getNearestHydratable(node, type) {
  // 这是一个死循环，或者说是“爬山”过程
  while (node !== null) {
    // 1. 检查当前节点是否是可注水节点
    // React 需要检查节点的类型（比如 div, span, img）和内容
    if (isHydratable(node, type)) {
      return node; // 找到了！这就是我们的锚点！
    }

    // 2. 如果当前节点不可注水（比如点击的是纯文本节点，或者一个没有子元素的 div）
    // 那我们就往上爬，看看它的父节点是不是可注水
    node = node.parentNode;
  }

  // 3. 如果爬到了根节点还没找到，那就说明在这个区域内没有锚点
  // React 就会进入 fallback 模式，或者抛出错误
  return null;
}

举个栗子：

假设用户点击了下面的 HTML 结构中的 span：

<div class="container">
  <div class="sidebar">
    <span>导航</span>
  </div>
  <div class="main-content">
    <h1>欢迎来到我的博客</h1>
    <button id="submit">提交</button>
  </div>
</div>

用户点击了 <button id="submit">。

React 调用 getNearestHydratable，传入节点是 <button>。
React 检查 <button> 本身。假设 <button> 在服务端 HTML 里是一个 div（为了演示方便），那类型不匹配，不能注水。
React 递归 parentNode，指向 <div class="main-content">。
React 检查 <div class="main-content">。假设这是一个可注水节点，类型匹配。
找到了！ <div class="main-content"> 就是我们的锚点。

一旦找到了锚点，React 就可以开始注水了。

第四部分：注水锚点——从点到面的“水漫金山”

找到了锚点之后，React 并没有就此止步。它还需要注水锚点及其子树（Children）。

这是为了确保用户看到的 UI 是完整的。如果只注水了父节点，而子节点还是服务端的 HTML，那用户点击父节点时，还是会报错。

所以，算法进入 attemptHydrationAtNode 阶段。

// 伪代码示例：attemptHydrationAtNode 逻辑
function attemptHydrationAtNode(node, fiber) {
  // 1. 先尝试注水当前节点
  // React 会比较服务端的 HTML 内容和客户端的 Fiber 内容
  // 如果完全一致，节点就“活”过来了（Hydrated）
  const isHydrated = hydrateNode(node, fiber);

  if (isHydrated) {
    // 2. 如果当前节点注水成功，我们需要继续注水它的子节点
    // 这就是“水漫金山”的原理
    const children = fiber.child;
    if (children) {
      attemptHydrationAtNode(node.firstChild, children);
    }
  } else {
    // 3. 如果当前节点注水失败怎么办？
    // 这时候 React 会尝试一种降级策略：
    // 它会尝试注水当前节点的第一个子节点，或者下一个兄弟节点
    // 这是为了处理一些边缘情况，比如服务端 HTML 和客户端结构略有不同
    fallbackHydration(node, fiber);
  }
}

这里有一个非常关键的细节： React 在注水子节点时，并不是简单地递归。它利用了 DOM 节点的父子关系。

React 会拿着 Fiber 树中的第一个子节点，去 DOM 树中找第一个子节点，比对；然后再找第二个，再比对。

这就是为什么我们在上面的例子中，一旦找到了 <div class="main-content"> 作为锚点，React 就能顺藤摸瓜，把里面的 <h1> 和 <button> 全部注水成功。

第五部分：实战演练——代码里的“猫捉老鼠”

为了让大家更直观地理解，我们来写一段模拟的代码，并手动模拟一下这个过程。

假设我们有一个 React 组件，它渲染了非常复杂的嵌套结构。

// 这是一个模拟的 React 组件
function ComplexComponent() {
  return (
    <div className="app-root">
      <nav className="sidebar">
        <ul>
          <li><a href="/home">首页</a></li>
          <li><a href="/profile">个人中心</a></li>
        </ul>
      </nav>
      <main className="content">
        <h1>欢迎</h1>
        <div className="card">
          <img src="avatar.jpg" alt="User" />
          <p>Hello World</p>
          <button onClick={handleClick}>点击我</button>
        </div>
      </main>
    </div>
  );
}

场景一：用户点击了“首页”链接

事件触发： 浏览器捕获到点击，调用 React 的事件处理。
获取 Target： getEventTarget 返回 <a href="/home">首页</a>。
寻找锚点：
- React 检查 <a> 标签。在 SSR HTML 中，<a> 对应的是 <li> 里的元素吗？假设对应。
- 如果对应，<a> 就是锚点。
- 如果不对应（比如 SSR 里是 <button>），React 就会向上找。
- 上找是 <li>，再上找是 <ul>。
注水： React 找到 <ul> 作为锚点。然后注水 <ul> -> <li> -> <a>。
结果： 只有侧边栏被注水了。主内容区还是空的，但在等待用户交互。如果用户这时候点击“提交”按钮，React 会发现“提交”按钮不在 <ul> 的子树里，它又会重新寻找锚点，这次可能会找到 <main>。

场景二：用户点击了“提交”按钮

事件触发： getEventTarget 返回 <button>点击我</button>。
寻找锚点：
- React 检查 <button>。
- SSR HTML 里，<button> 对应的是 <div className="card"> 里的元素吗？假设对应。
- 如果对应，<button> 就是锚点。
- 如果不对应，React 会向上找。上找是 <p>，再上找是 <div className="card">。
- 假设 <div className="card"> 是可注水节点。
注水： React 找到 <div className="card">。注水它，然后注水它的子节点 <img>, <p>, <button>。
结果： 只有卡片区域被注水。侧边栏是空的。

第六部分：算法的“软肋”——当找不到锚点时

虽然 Selective Hydration 很聪明，但它也有它的极限。如果用户点击了一个它完全无法识别的节点，或者点击了一个纯文本节点，算法就会陷入僵局。

让我们看看 getNearestHydratable 的完整逻辑，特别是那些边缘情况的处理。

function getNearestHydratable(node, type) {
  while (node !== null) {
    const nodeType = node.nodeType;
    const nodeName = node.nodeName;

    // 情况 1：文本节点
    // React 不太喜欢直接注水纯文本节点，除非它是某个标签的内容
    if (nodeType === Node.TEXT_NODE) {
      // 如果文本节点不为空，它可能是一个有效的文本锚点
      // 但通常 React 更倾向于找标签
      if (node.nodeValue !== '') {
        return node;
      }
    } 
    // 情况 2：元素节点
    else if (nodeType === Node.ELEMENT_NODE) {
      // 这里有一段非常长的 switch-case 语句
      // React 列出了所有它支持的标签：div, span, img, button, input...
      switch (nodeName) {
        case 'DIV':
        case 'SPAN':
        case 'IMG':
        case 'BUTTON':
        // ... 更多标签
          return node;
        default:
          // 如果是 SVG 标签或者不支持的标签，继续往上找
          break;
      }
    }

    // 继续爬山
    node = node.parentNode;
  }
  return null;
}

关键点： 如果 getNearestHydratable 返回了 null，React 就知道在这个点击位置“无路可走”了。

这时候，React 会怎么做？它会触发 Hydration Suspense 或者 Hydration Mismatch Error。

它会抛出一个错误，告诉开发者：“嘿，我在这个位置找不到可注水的锚点了，可能是服务端 HTML 和客户端代码不匹配，或者是你点击了一个不存在的元素。”

这就是为什么我们在开发 SSR 应用时，必须非常小心地处理 DOM 结构。 你不能随便在服务端 HTML 里加一个 <div> 而在客户端 React 组件里删掉它，否则用户一点击那个 div，应用就崩了。

第七部分：性能与用户体验的平衡术

我们讲了这么多源码，最后得回到“钱”和“体验”上来。

Selective Hydration 最大的贡献是什么？是 CLS (Cumulative Layout Shift，累积布局偏移) 的降低。

想象一下，如果 React 必须等整个页面都注水完了才显示，那么用户可能会看到：

一堆空白。
然后突然文字和按钮全部“蹦”出来。

这种突兀的跳动就是 CLS。而 Selective Hydration 做的是：用户手指一按，哪里亮哪里。

用户点击了按钮，按钮立刻显示出来，周围的内容瞬间填充。用户感觉不到“加载中”，因为 React 一直都在后台默默地注水其他区域，直到用户切换页面或滚动。

这就像是在餐馆吃饭。以前（旧版 React），服务员必须等一整桌菜都上齐了，才敢上第一道菜。现在（Selective Hydration），你点了哪个菜，服务员就先上哪个菜。虽然最后大家都能吃到，但中间的过程体验完全不同。

第八部分：代码层面的“作弊”——如何利用这个特性

既然我们知道了这个算法，能不能在写代码时“欺骗”它，或者利用它？

技巧 1：关键交互优先渲染
如果你的页面有一个非常关键的“立即行动”按钮（CTA），确保这个按钮在 DOM 结构中尽可能“浅”，或者确保它的父级结构在 SSR 时是确定的。

技巧 2：避免在 SSR HTML 中使用不可见的容器
不要在服务端 HTML 里放一堆 <div class="hidden"></div>。React 在注水时，如果发现这些 div 的内容和服务端不一致（比如服务端是空的，客户端有内容），就会报错。这会强制触发全量 Hydration。

技巧 3：Suspense 的配合
Selective Hydration 通常和 Suspense 配合使用。当某个组件正在加载（比如异步组件），React 会暂停注水那个区域。如果用户点击了那个区域，React 会优先注水这个区域，从而触发 Suspense 的 fallback 状态。这形成了一个完美的闭环。

第九部分：源码深挖——ReactFiberHydrationComponent.js 的细节

让我们把目光聚焦到 React 源码的 ReactFiberHydrationComponent.js。这个文件是 Selective Hydration 的心脏。

这里面有一个函数叫 getEventTarget，还有一个叫 getNearestHydratableNode。

// 源码片段（简化版）
function getNearestHydratableNode(node, type) {
  while (node !== null) {
    // 检查是否匹配
    if (isHydratable(node, type)) {
      return node;
    }
    // 向上查找
    node = node.parentNode;
  }
  return null;
}

这里面的 isHydratable 函数非常关键。它不仅检查标签名，还检查属性。比如，React 18 对 input 标签的 value 属性非常敏感。

如果你在服务端 HTML 里写的是 <input value="foo">，而客户端 React 组件里没写 defaultValue，React 会认为这是一个 Hydration Mismatch。

Selective Hydration 的算法在寻找锚点时，也会检查这些属性是否匹配。如果点击的节点属性和服务端不匹配，它也会继续向上找。

这解释了为什么有时候点击一个 div 会报错，但点击它的父级 section 却没问题。因为父级 section 的属性和服务端更接近。

第十部分：总结与展望

好了，各位，我们今天的“源码侦探”之旅就到这里。

回顾一下，Selective Hydration 的核心算法其实就是三个步骤：

捕获： 通过 getEventTarget 获取用户点击的 DOM 节点。
回溯： 通过 getNearestHydratable 向上寻找可注水的锚点。
注水： 通过 attemptHydrationAtNode 注水锚点及其子树。

这个算法体现了 React 团队对用户体验极致的追求。它不再是一味地追求“全量注水”的完美主义，而是学会了“有的放矢”的实用主义。

它告诉我们一个道理：在 Web 开发中，有时候“足够好”比“完美”更重要。 只要用户看到的那部分是正确的，其他的可以慢慢加载。

未来的 React（比如 React Server Components, Next.js 13+）会进一步强化这个特性。随着服务端组件的普及，Hydration 的范围会越来越小，Selective Hydration 的重要性也会越来越高。

所以，下次当你再看到那个红色的 Hydration failed 错误时，不要慌张。拿起你的放大镜，看看是不是用户点击了一个不存在的节点，或者是你的 SSR HTML 和客户端代码“三观不合”。

希望今天的讲座能让你对 Selective Hydration 有更深的理解。记住，代码是写给人看的，算法是写给浏览器和 React 看的。让 React 乖乖地为你工作，而不是让你被它折磨！

好了，问题环节开始！谁想问关于 getNearestHydratable 循环次数的问题？还是想问关于 HydrationState 的内存占用？来吧，让我们继续深入！