什么是 `Dehydration` 与 `Hydration`？深度解析 React 在服务端渲染中的“注水”与“脱水”过程 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同仁，大家好。今天我们将深入探讨 React 服务端渲染（SSR）中的核心机制——“脱水”（Dehydration）与“注水”（Hydration）。这两个概念，对于构建高性能、用户体验卓越的 React 应用至关重要，它们是连接服务器端预渲染内容与客户端交互能力的桥梁。

一、引言：SSR 的魅力与挑战

在前端开发的演进中，单页应用（SPA）以其流畅的用户体验和强大的交互性占据了主流。然而，纯客户端渲染（CSR）模式也暴露出了一些局限性，例如：

首屏加载时间（FCP/LCP）：用户需要等待 JavaScript 文件下载、解析、执行，然后才能看到页面内容，这导致了较差的初始加载体验。
搜索引擎优化（SEO）：尽管现代搜索引擎在抓取和索引 JavaScript 内容方面有所进步，但对于某些爬虫或复杂应用而言，直接提供渲染好的 HTML 仍然是更稳妥、更高效的方案。

服务端渲染（SSR）应运而生，旨在解决这些问题。它允许我们在服务器上预先执行 React 组件，将它们渲染成静态 HTML 字符串，然后将这个 HTML 连同必要的 JavaScript 和 CSS 一起发送给客户端。这样，用户在浏览器接收到 HTML 后，可以立即看到页面的骨架内容，大大提升了首屏渲染速度。

然而，SSR 并非银弹。当浏览器接收到这些由服务器渲染的 HTML 后，它们只是静态的文本，不具备任何交互能力。例如，按钮点击没有响应，表单无法输入。为了让这些静态 HTML 变得“活”起来，具备 React 应用应有的交互性，我们需要一套机制来将客户端的 React 应用“嫁接”到这些预渲染的 HTML 上。这个过程，就是我们今天讨论的“注水”（Hydration），而它所依赖的，则是服务器端“脱水”（Dehydration）出的基础结构和数据。

简单来说：

脱水（Dehydration）：在服务器上，将 React 组件树渲染成静态 HTML 字符串，并准备好初始状态数据，以便客户端能够快速接管。
注水（Hydration）：在客户端，React 框架接管服务器发送的静态 HTML，将其转化为可交互的 React 组件树，并挂载事件监听器，恢复应用程序的完整功能。

理解这两个过程，是掌握高性能 React SSR 的基石。

二、 React SSR 概览：为何需要服务端渲染？

在深入探讨“脱水”与“注水”之前，我们先快速回顾一下 SSR 的核心价值。

客户端渲染 (CSR) 的工作流程：

浏览器请求页面。
服务器发送一个空的 HTML 文件，其中包含 <div id="root"></div> 和 <script src="bundle.js"></script>。
浏览器下载并解析 HTML。
浏览器下载 bundle.js。
bundle.js 执行，React 应用在客户端启动，渲染内容到 <div id="root"></div>。
用户看到并可以交互页面。

SSR 的工作流程：

浏览器请求页面。
服务器接收请求，执行 React 应用逻辑，将其渲染成完整的 HTML 字符串。
服务器将此 HTML 字符串连同必要的 JavaScript (bundle.js) 一起发送给浏览器。
浏览器下载并解析 HTML，用户立即看到页面的完整内容（尽管此时尚不可交互）。
浏览器下载 bundle.js。
bundle.js 执行，React 在客户端启动，并对服务器渲染的 HTML 进行“注水”操作。
页面变为完全可交互。

SSR 的优势：

特性	客户端渲染 (CSR)	服务端渲染 (SSR)
首屏加载	慢，需等待 JS 加载执行	快，直接返回完整 HTML
用户体验	FCP/LCP 较差	FCP/LCP 优秀，用户感知更快
SEO	依赖爬虫执行 JS，可能存在风险	直接提供可索引 HTML，SEO 友好
交互性	JS 加载后立即具备	JS 加载并注水完成后具备
服务器负载	低	高（需要执行渲染逻辑）
开发复杂性	低	高（需要考虑同构、数据预取、环境差异等）
TTI (Time to Interactive)	通常与 FCP/LCP 接近，或略晚	FCP/LCP 显著快于 TTI，存在一段“不可交互”的空白期

SSR 的关键在于，它在服务器上生成了“第一次绘制”（First Paint）所需的全部内容。然而，如何让这个静态的 HTML 变得动态且可交互，正是“脱水”与“注水”要解决的核心问题。

三、 “脱水”：从 React 组件到静态 HTML

“脱水”是服务器端的工作，其核心任务是将 React 组件树转换为一个静态的 HTML 字符串。这个过程不仅仅是简单地拼接字符串，React 在其中嵌入了特殊的标记，以便客户端的“注水”过程能够高效地识别和接管这些元素。

3.1 概念：服务器端渲染的本质

在服务器环境中，我们没有浏览器 DOM，因此无法像在客户端那样直接操作 DOM 节点。React 为服务器端提供了一套专门的 API，用于将组件渲染成字符串。这个字符串就是我们所说的“脱水”后的产物。

3.2 核心机制：`ReactDOMServer` API

React 提供了 ReactDOMServer 模块来处理服务器端渲染。其中最常用的方法是：

ReactDOMServer.renderToString(element): 将 React 元素渲染为 HTML 字符串。它是同步的，会等待整个组件树渲染完毕后才返回结果。这是最常见的 SSR 方法，但在大型应用中可能会阻塞主线程。
ReactDOMServer.renderToStaticMarkup(element): 与 renderToString 类似，但它不会在 HTML 中添加 React 特有的 data-reactid 或 data-reactroot 等属性。这适用于只希望渲染纯静态 HTML，而不需要客户端“注水”的场景（例如生成邮件模板或静态内容）。
ReactDOMServer.renderToPipeableStream(element) (React 18+): 这是一个新的 API，用于实现流式 SSR。它返回一个可读流，允许将 HTML 分块发送到客户端，支持 React 18 的 Suspense 特性，从而实现更快的 FCP 和更优的用户体验。

我们主要关注 renderToString 和 renderToPipeableStream，因为它们是实现可交互 SSR 的基础。

3.3 HTML 结构中的 React 标记

当使用 renderToString 或 renderToPipeableStream 渲染时，React 会在生成的 HTML 元素中注入特定的 data- 属性。这些属性是 React 识别和管理 DOM 树的关键。

例如，一个简单的 React 组件：

// src/components/App.js
import React from 'react';

const App = ({ message }) => {
  return (
    <div className="container">
      <h1>Hello from SSR!</h1>
      <p>{message}</p>
      <button>Click Me</button>
    </div>
  );
};

export default App;

在服务器端使用 renderToString 渲染后，生成的 HTML 可能看起来像这样：

<div data-reactroot="" class="container">
  <h1>Hello from SSR!</h1>
  <p data-reactid="1-1">{message}</p>
  <button data-reactid="1-2">Click Me</button>
</div>

data-reactroot="": 标识了 React 应用的根元素。
data-reactid="...": 标识了由 React 管理的特定组件或 DOM 节点。这些 ID 在 React 内部用于跟踪组件的生命周期和状态。

这些属性在 React 客户端进行“注水”时至关重要，它们帮助 React 快速地将虚拟 DOM 与服务器渲染的真实 DOM 进行匹配，而无需从头构建整个 DOM 树。

3.4 状态与数据传输：服务器端数据的“脱水”

仅仅渲染 HTML 是不够的。一个真实的 React 应用往往依赖于初始数据或状态（例如，从 API 获取的用户信息、Redux store 中的数据、Apollo Client 的缓存等）。这些数据在服务器端渲染时被使用，也必须“脱水”并传输到客户端，以便客户端应用能够以相同的初始状态启动。

最常见的模式是将这些初始数据序列化为 JSON 字符串，然后注入到 HTML 的 <script> 标签中，通常放在 window 对象的一个全局属性下。

<!DOCTYPE html>
<html>
<head>
  <title>React SSR App</title>
</head>
<body>
  <div id="root"><!-- 服务器渲染的 HTML 内容 --></div>
  <script>
    // 将初始状态数据注入到全局变量
    window.__INITIAL_STATE__ = {
      message: "This message came from the server!",
      user: { id: 1, name: "Alice" }
    };
  </script>
  <script src="/static/bundle.js"></script>
</body>
</html>

在服务器端，这可能涉及到：

数据预取（Data Fetching）：在渲染组件之前，通过异步请求获取所需数据。
状态管理库集成：如果使用 Redux、Zustand 或 Apollo Client 等状态管理库，需要在服务器端构建其 store 或 cache，并填充数据。
序列化：将这些数据（通常是 JavaScript 对象）安全地序列化为 JSON 字符串。
- 注意：序列化时需警惕 XSS 攻击。JSON.stringify 足够安全，但在注入到 script 标签时，如果数据本身包含 <、> 等特殊字符，仍然需要额外的转义。一种常见做法是使用 serialize-javascript 库，或者简单地在 JSON.stringify 后，将 </script> 替换为 </script>。

3.5 代码示例：服务器端脱水

这是一个简化的 Node.js 服务器，用于演示“脱水”过程：

// server/index.js
import express from 'express';
import React from 'react';
import ReactDOMServer from 'react-dom/server';
import App from '../src/components/App'; // 我们的 React App 组件

const app = express();
const PORT = 3000;

// 模拟数据预取
const fetchData = async () => {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve({
        message: "Hello from Server!",
        items: ['Item A', 'Item B', 'Item C']
      });
    }, 100); // 模拟网络延迟
  });
};

app.get('/', async (req, res) => {
  const initialData = await fetchData(); // 预取数据

  // 1. 将 React 组件渲染为 HTML 字符串 (脱水)
  const appMarkup = ReactDOMServer.renderToString(
    <App message={initialData.message} items={initialData.items} />
  );

  // 2. 将初始数据序列化并注入到 HTML (数据脱水)
  const serializedInitialState = JSON.stringify(initialData).replace(/</g, '\u003c'); // 防止 XSS

  res.send(`
    <!DOCTYPE html>
    <html lang="en">
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
      <title>React SSR Dehydration</title>
      <style>
        body { font-family: sans-serif; margin: 20px; }
        .container { border: 1px solid #ccc; padding: 20px; border-radius: 8px; }
        button { padding: 10px 15px; background-color: #007bff; color: white; border: none; border-radius: 4px; cursor: pointer; }
        button:hover { background-color: #0056b3; }
      </style>
    </head>
    <body>
      <div id="root">${appMarkup}</div>
      <script>
        // 注入脱水后的初始状态
        window.__INITIAL_STATE__ = ${serializedInitialState};
      </script>
      <script src="/static/bundle.js"></script>
    </body>
    </html>
  `);
});

// 假设 /static 目录存放客户端打包的 bundle.js
app.use('/static', express.static('dist/static'));

app.listen(PORT, () => {
  console.log(`Server listening on port ${PORT}`);
});

// src/components/App.js (客户端和服务端共用)
import React, { useState, useEffect } from 'react';

const App = ({ message, items: initialItems }) => {
  const [count, setCount] = useState(0);
  const [items, setItems] = useState(initialItems);

  useEffect(() => {
    // 这是一个只在客户端运行的副作用
    console.log("App component mounted on client!");
  }, []);

  const handleButtonClick = () => {
    setCount(prevCount => prevCount + 1);
  };

  const addItem = () => {
    setItems(prevItems => [...prevItems, `New Item ${prevItems.length + 1}`]);
  };

  return (
    <div className="container">
      <h1>{message}</h1>
      <p>Current Count: {count}</p>
      <button onClick={handleButtonClick}>Increment Count</button>
      <h2>Items:</h2>
      <ul>
        {items.map((item, index) => (
          <li key={index}>{item}</li>
        ))}
      </ul>
      <button onClick={addItem}>Add New Item</button>
    </div>
  );
};

export default App;

在这个例子中，App 组件在服务器上被渲染成 HTML，同时 initialData 被序列化并注入到 window.__INITIAL_STATE__。这就是“脱水”的完整过程。

四、 “注水”：激活静态 HTML

“注水”是客户端的工作，其核心是将服务器发送的静态 HTML 转化为一个完全可交互的 React 应用。这个过程包括识别服务器渲染的 DOM 结构、附加事件监听器、恢复应用程序状态，并使组件具备完整的生命周期和响应能力。

4.1 概念：客户端接管

当浏览器接收到服务器渲染的 HTML 后，它会立即解析并显示内容。此时，用户可以看到页面，但无法进行任何交互。当客户端的 JavaScript (bundle.js) 加载并执行后，React 会启动“注水”过程。

“注水”的目标是：

复用 DOM 结构：而不是销毁服务器渲染的 HTML 并从头重新渲染，React 会尝试复用现有的 DOM 节点。
匹配虚拟 DOM 与真实 DOM：React 内部会构建一个虚拟 DOM 树，然后将其与服务器渲染的真实 DOM 树进行对比。
附加事件监听器：将 React 组件中定义的事件处理函数（如 onClick、onChange）附加到对应的 DOM 节点上。
恢复状态：利用服务器端“脱水”传输过来的初始状态数据，初始化客户端应用的状态管理库或组件内部状态。

4.2 核心机制：`ReactDOM.hydrate` 与 `ReactDOM.hydrateRoot`

React 提供了专门的 API 来进行“注水”：

ReactDOM.hydrate(element, container, [callback]) (React 17 及更早版本): 这是传统的注水 API。它会尝试将 element 挂载到 container DOM 节点上，并接管其内部的服务器渲染内容。如果服务器渲染的 HTML 与客户端渲染的虚拟 DOM 结构不匹配，hydrate 会发出警告，并可能重新渲染整个不匹配的子树。
ReactDOM.hydrateRoot(container, initialChildren, options) (React 18+): 这是 React 18 引入的新的并发根 API。它取代了 hydrate，并与 ReactDOM.createRoot 类似，提供了更强大的并发特性，包括选择性注水（Selective Hydration）和更好的性能。它是 createRoot 的 SSR 对应版本。

4.3 匹配算法：虚拟 DOM 与真实 DOM 的比对

“注水”的关键在于匹配。React 在客户端会重新执行组件的渲染逻辑，生成一个虚拟 DOM 树。然后，它会遍历服务器渲染的真实 DOM 树，并尝试将虚拟 DOM 节点与真实 DOM 节点一一对应起来。

这个匹配过程是基于以下原则进行的：

根节点匹配：首先，React 会检查 hydrate 或 hydrateRoot 指定的容器元素（例如 <div id="root"></div>）。
元素类型匹配：React 会比较虚拟 DOM 节点和真实 DOM 节点的标签类型（例如 div vs p）。
属性匹配：React 会比较节点的属性（className、id 等）。特别是服务器端注入的 data-reactid 和 data-reactroot 属性，它们是重要的提示。
子节点顺序：子节点的顺序也必须一致。

如果 React 发现虚拟 DOM 树与真实 DOM 树之间存在差异（例如，服务器端渲染了一个 div，而客户端组件渲染了一个 p），它会发出警告（在开发模式下），并选择抛弃服务器渲染的 DOM 节点，转而使用客户端渲染的节点来替换。这被称为“注水错误”（Hydration Mismatch），是需要极力避免的，因为它会抵消 SSR 带来的性能优势，导致页面内容在注水时“闪烁”或重新布局。

避免注水错误的关键在于确保服务器和客户端在第一次渲染时生成完全相同的 HTML 结构。

4.4 事件处理：重新绑定

服务器渲染的 HTML 只是静态的标记，不包含任何事件监听器。在“注水”过程中，React 会遍历其虚拟 DOM 树，识别所有需要事件处理的节点，并将相应的事件监听器附加到真实 DOM 节点上。React 使用事件委托（Event Delegation）机制，将大部分事件监听器附加到根节点（例如 document 或 body），从而高效地处理事件。

4.5 状态恢复：客户端数据的“注水”

客户端应用程序启动时，它会读取服务器端“脱水”注入的 window.__INITIAL_STATE__。然后，它使用这些数据来初始化应用程序的全局状态管理（如 Redux store）或组件的本地状态。

// client/index.js
import React from 'react';
import ReactDOM from 'react-dom/client'; // React 18 client API
import App from '../src/components/App';

// 从服务器注入的全局变量中获取初始状态
const initialData = window.__INITIAL_STATE__;
delete window.__INITIAL_STATE__; // 清理全局变量

// 确保 App 组件能接收到初始数据
const root = ReactDOM.hydrateRoot(
  document.getElementById('root'),
  <App message={initialData.message} items={initialData.items} />
);

// 如果需要，可以在注水完成后执行一些操作
// root.render(<App message={initialData.message} items={initialData.items} />); // 仅用于开发模式下的 StrictMode 或其他特殊情况

通过这种方式，客户端应用在启动时就拥有了与服务器端渲染时相同的初始状态，避免了二次数据加载，确保了用户看到的页面内容在注水前后保持一致。

4.6 代码示例：客户端注水

// client/index.js
import React from 'react';
import ReactDOM from 'react-dom/client'; // 使用 React 18 的新客户端 API
import App from '../src/components/App';

// 从服务器注入的全局变量中获取初始状态
const initialData = window.__INITIAL_STATE__ || { message: "Default Message", items: [] };
delete window.__INITIAL_STATE__; // 移除全局变量，避免污染

console.log("Client-side hydration starting with initial data:", initialData);

const rootElement = document.getElementById('root');

// 使用 React 18 的 hydrateRoot 进行注水
// hydrateRoot 接收两个参数：容器 DOM 元素和要渲染的 React 元素。
// 它会尝试复用服务器渲染的 DOM，并使其可交互。
ReactDOM.hydrateRoot(
  rootElement,
  <React.StrictMode> {/* StrictMode 仅在开发模式下运行，用于发现潜在问题 */}
    <App message={initialData.message} items={initialData.items} />
  </React.StrictMode>
);

console.log("Client-side hydration complete.");

配合之前的 server/index.js 和 src/components/App.js，当浏览器加载 bundle.js 时，它会执行上述 client/index.js 中的代码。ReactDOM.hydrateRoot 会找到 <div id="root"> 元素，并尝试将 App 组件“注水”到其中，使其具备交互能力。用户现在可以点击按钮、添加新项目了。

五、深度对比与机制：`renderToString` vs. `renderToPipeableStream` vs. `hydrate` vs. `hydrateRoot`

React 18 带来了 SSR 和 Hydration 的重大改进，主要是通过引入流式 SSR 和并发注水。理解这些新旧 API 的差异对于构建现代 React SSR 应用至关重要。

5.1 服务器端渲染 API 对比

特性	`ReactDOMServer.renderToString(element)` (React 17-)	`ReactDOMServer.renderToPipeableStream(element)` (React 18+)
渲染模式	同步阻塞	异步非阻塞，流式传输
性能	整个页面渲染完成后一次性返回，可能导致 FCP 延迟	HTML 分块发送，允许浏览器逐步渲染，更快的 FCP
Suspense	不支持，Suspense 边界下的内容会延迟整个页面渲染	支持，Suspense 边界允许流式传输 fallback 内容，后续再填充真实内容
错误处理	整个渲染过程中的错误会阻塞整个页面渲染	错误处理更细粒度，可以捕获特定组件树的错误
使用场景	简单应用，或不追求极致性能的场景	复杂应用，追求高性能和用户体验，利用 Suspense 进行数据加载
返回类型	`string`	`ReadableStream` (Node.js Stream API)

renderToPipeableStream 的工作原理：

renderToPipeableStream 不会返回一个完整的 HTML 字符串，而是返回一个包含两个主要部分的对象：

pipe(res): 一个方法，用于将渲染流直接管道传输到 Node.js 响应流。
onShellReady, onShellError, onAllReady: 回调函数。
- onShellReady: 当 React 渲染出页面的“外壳”（shell，即骨架 HTML，不包含所有 Suspense 内部的异步内容）时触发。此时可以发送页面的 <head> 和主体骨架。
- onAllReady: 当所有 Suspense 边界内的异步数据都加载并渲染完毕时触发。
- onShellError: 当渲染外壳时发生错误时触发。

这使得浏览器可以在所有数据都准备好之前就开始显示页面，从而显著提升用户感知性能。

5.2 客户端注水 API 对比

特性	`ReactDOM.hydrate(element, container, [callback])` (React 17-)	`ReactDOM.hydrateRoot(container, initialChildren, options)` (React 18+)
根 API	旧的根 API	新的并发根 API
注水模式	阻塞式，一旦开始注水，会尝试处理整个应用树	并发式，支持选择性注水（Selective Hydration）
性能	整个注水过程可能耗时，阻塞主线程，影响 TTI	可以优先注水用户交互的区域，非关键部分可以延迟，改善 TTI
事件处理	挂载到 `document`	挂载到 `document` (但处理方式更智能，支持事件重放)
Suspense	不支持（至少在注水阶段无法利用 Suspense 带来的优势）	完美支持，可以与流式 SSR 结合，实现渐进式注水
过渡 API	不支持 `startTransition`	支持 `startTransition`，允许在注水过程中进行平滑的 UI 更新

hydrateRoot 和选择性注水的工作原理：

hydrateRoot 开启了 React 18 的并发特性。它不会一次性地接管整个应用。相反，它会根据用户交互的优先级来注水。例如：

如果用户点击了一个尚未注水完成的区域，React 会优先注水该区域，使其立即响应。
非关键区域的注水可以被推迟，让浏览器有更多空闲时间来处理其他任务。
结合 Suspense 和 renderToPipeableStream，可以实现“渐进式注水”（Progressive Hydration）。服务器可以先发送一个骨架 HTML，当某个 Suspense 边界内的数据准备好后，服务器发送该部分的 HTML 片段，客户端 React 可以在不重新注水整个页面的情况下，单独注水该片段。

这大大改善了大型应用的交互性，减少了用户等待 TTI 的时间。

六、数据“脱水”与“注水”：状态管理与数据流

数据是应用程序的灵魂。在 SSR 中，不仅要渲染组件的结构，更要确保组件所依赖的数据能够在服务器和客户端之间无缝传递。

6.1 通用的数据脱水模式

如前所述，最常见的方式是使用 window.__INITIAL_STATE__ 全局变量。

<script>
  window.__INITIAL_STATE__ = { /* JSON 序列化的数据 */ };
</script>

在服务器端：

const preloadedState = { /* ... 你的应用数据 ... */ };
const serializedState = JSON.stringify(preloadedState).replace(/</g, '\u003c');
// 将 serializedState 注入到 HTML

在客户端：

const preloadedState = window.__INITIAL_STATE__;
delete window.__INITIAL_STATE__; // 清理
// 使用 preloadedState 初始化你的状态管理器或组件

6.2 各种状态管理库的脱水与注水

1. Context API:
React 的 Context API 在 SSR 中可以正常工作。你需要在服务器端提供 Context 的初始值，客户端在注水时也提供相同的值。

// Server
const App = ({ initialValue }) => (
  <MyContext.Provider value={initialValue}>
    <MyComponent />
  </MyContext.Provider>
);

// Client
const initialValue = window.__INITIAL_STATE__.contextValue;
ReactDOM.hydrateRoot(
  document.getElementById('root'),
  <MyContext.Provider value={initialValue}>
    <App />
  </MyContext.Provider>
);

2. Redux / Zustand 等全局状态管理库:
这些库通常有一个 store 对象。在服务器端，你需要：
a. 创建一个 Redux store 实例。
b. 预取所有需要的数据，并 dispatch action 来填充 store。
c. 在渲染前，通过 store.getState() 获取完整的 store 状态。
d. 将这个状态序列化并注入到 window.__INITIAL_STATE__。

在客户端，你需要：
a. 从 window.__INITIAL_STATE__ 中读取序列化的状态。
b. 使用这些状态来初始化 Redux store。
c. 然后将这个初始化的 store 提供给你的 React 应用（例如通过 Provider）。

// Server-side (simplified)
import { createStore } from 'redux';
import { renderToString } from 'react-dom/server';
import { Provider } from 'react-redux';
import rootReducer from '../src/reducers';
import App from '../src/components/App';

const store = createStore(rootReducer, { /* preloaded initial state from data fetching */ });
const html = renderToString(
  <Provider store={store}>
    <App />
  </Provider>
);
const preloadedState = store.getState();
const serializedState = JSON.stringify(preloadedState);
// ... inject serializedState into HTML

// Client-side (simplified)
import { createStore } from 'redux';
import { hydrateRoot } from 'react-dom/client';
import { Provider } from 'react-redux';
import rootReducer from '../src/reducers';
import App from '../src/components/App';

const preloadedState = window.__INITIAL_STATE__;
const store = createStore(rootReducer, preloadedState);

hydrateRoot(
  document.getElementById('root'),
  <Provider store={store}>
    <App />
  </Provider>
);

3. Apollo Client / React Query 等数据获取库:
这些库有自己的内部缓存。
在服务器端：
a. 创建一个 Apollo Client 或 React Query 客户端实例。
b. 在渲染组件之前，执行所有组件所需的 GraphQL 查询或数据请求，填充客户端缓存。
c. 使用 getDataFromTree (Apollo) 或 dehydrate (React Query) 将缓存中的数据提取出来。
d. 序列化这些数据并注入到 window.__APOLLO_STATE__ 或 window.__REACT_QUERY_STATE__。

在客户端：
a. 从 window.__APOLLO_STATE__ 或 window.__REACT_QUERY_STATE__ 中读取数据。
b. 使用这些数据来恢复 Apollo Client 或 React Query 的缓存。
c. 然后将这个客户端实例提供给你的 React 应用。

6.3 序列化复杂对象

JSON.stringify 可以处理基本类型、数组和普通对象，但对于 Date、Map、Set、RegExp 或自定义类的实例，它会将其转换为字符串、空对象或丢失信息。

解决方案：

手动转换：在序列化前将 Date 对象转换为 ISO 字符串，Map/Set 转换为数组。在客户端反序列化时再转换回来。
库辅助：使用像 superjson 或 serialize-javascript 这样的库，它们提供了更强大的序列化/反序列化能力，可以处理更多的数据类型。
只存储纯数据：尽量确保 __INITIAL_STATE__ 中存储的都是纯 JavaScript 对象和基本类型。

6.4 安全性考虑：XSS 攻击

将 window.__INITIAL_STATE__ 注入到 HTML 中存在潜在的 XSS 风险，如果数据没有被正确转义。

<script>window.__INITIAL_STATE__ = ${JSON.stringify(data)};</script>

如果 data 中包含 </script> 字符串，它会提前关闭 <script> 标签，导致后续内容被解析为 HTML，从而可能注入恶意代码。

最佳实践：
在 JSON.stringify 之后，将所有 </script> 替换为 </script> (或 u003c/script>)。

const serializedState = JSON.stringify(data).replace(/</g, '\u003c');
// 或者使用更健壮的库，如 serialize-javascript
// const serialize = require('serialize-javascript');
// const serializedState = serialize(data, { is</a>JSON: true });

七、性能优化与最佳实践

为了充分发挥 SSR 的优势，并确保“脱水”与“注水”过程高效，我们需要遵循一些最佳实践。

7.1 避免 DOM Mismatches

这是 SSR 最常见的陷阱。如果服务器渲染的 HTML 与客户端渲染的虚拟 DOM 不完全匹配，React 会发出警告，并且可能不得不重新渲染整个不匹配的子树，这会损失 SSR 带来的性能优势。

常见原因及解决方案：

客户端独有的代码：在服务器上运行了依赖 window 或 document 等浏览器全局对象的代码。
- 解决方案：使用 typeof window !== 'undefined' 进行条件判断，或者将这些代码放入 useEffect 或 componentDidMount 生命周期方法中，确保它们只在客户端执行。对于组件，可以考虑动态导入 (React.lazy + Suspense 或 loadable-components)，将它们标记为 ssr: false。
时间戳或随机 ID：在服务器和客户端生成了不同的时间戳或随机 ID。
- 解决方案：避免在渲染过程中生成随机值。如果需要，可以在服务器上生成并作为初始状态传递给客户端。
CSS-in-JS 库：一些 CSS-in-JS 库（如 styled-components、Emotion）需要特殊的服务器配置来收集样式并注入到 HTML 中，否则客户端可能会生成不同的样式类名。
- 解决方案：查阅相应库的 SSR 文档，通常需要使用 ServerStyleSheet 或 extractCritical 等 API。
浏览器差异：浏览器可能会自动纠正或添加一些 HTML 元素（例如，表格中的 <tbody>）。
- 解决方案：确保你的 React 代码生成的 HTML 是语义正确的，尽量避免依赖浏览器自动修复。

7.2 条件渲染与客户端独有组件

对于只在客户端运行的组件或逻辑，应谨慎处理：

// 错误示例：在服务器上会报错，因为 window 不存在
const MyClientOnlyComponent = () => {
  const [width, setWidth] = useState(window.innerWidth);
  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);
    return () => window.removeEventListener('resize', handleResize);
  }, []);
  return <div>Window Width: {width}</div>;
};

// 正确示例 1：条件判断
const MyClientOnlyComponentSafe = () => {
  const [width, setWidth] = useState(0); // 初始值在服务器上渲染
  useEffect(() => {
    if (typeof window !== 'undefined') {
      setWidth(window.innerWidth);
      const handleResize = () => setWidth(window.innerWidth);
      window.addEventListener('resize', handleResize);
      return () => window.removeEventListener('resize', handleResize);
    }
  }, []);
  return <div>Window Width: {width}</div>;
};

// 正确示例 2：动态导入 (推荐)
import dynamic from 'next/dynamic'; // 或使用 loadable-components

const DynamicClientOnlyComponent = dynamic(() => import('./ClientOnlyComponent'), {
  ssr: false, // 明确告知不要在服务器端渲染此组件
  loading: () => <p>Loading client-side component...</p>,
});

// ClientOnlyComponent.js 内容：
// const ClientOnlyComponent = () => { /* ... 依赖 window 的代码 ... */ };
// export default ClientOnlyComponent;

7.3 代码分割 (Code Splitting)

将应用程序代码分割成更小的块，按需加载，可以显著减少初始 JavaScript 包的大小，从而加快 TTI。在 SSR 环境中，这需要额外的配置。

React.lazy + Suspense: React 18 的 renderToPipeableStream 完美支持，可以在服务器端渲染 fallback，客户端加载实际组件。
loadable-components / Next.js 的 dynamic: 这些库在 SSR 中提供了更强大的代码分割能力，它们可以在服务器端收集哪些动态组件被渲染了，并将它们的 JavaScript 模块预加载到客户端。

7.4 渐进式注水 (Progressive Hydration) 与选择性注水 (Selective Hydration)

渐进式注水：结合 renderToPipeableStream 和 Suspense。服务器可以先发送页面的骨架 HTML，当 Suspense 边界内的数据准备好后，再发送该部分的 HTML。客户端在接收到这些片段后，可以单独对它们进行注水，而无需等待整个页面。
选择性注水：React 18 的 hydrateRoot 允许 React 优先注水那些用户正在与之交互的区域（例如，点击的按钮所在的组件），即使其他部分的注水尚未完成。这确保了关键交互的即时响应。

7.5 Critical CSS

为了避免页面闪烁（FOUC – Flash of Unstyled Content），应将首屏所需的关键 CSS 内联到 HTML 的 <head> 中。这确保了在 JavaScript 和外部 CSS 文件加载之前，页面就能以正确的样式呈现。许多 CSS-in-JS 库和构建工具都提供了提取 Critical CSS 的能力。

7.6 优化数据传输

最小化 __INITIAL_STATE__：只传输客户端启动所需的最小数据集，避免传输不必要的或重复的数据。
压缩：确保服务器端对 HTML 和 JavaScript 文件进行 Gzip 或 Brotli 压缩。

7.7 调试 Hydration 错误

当出现注水不匹配时，React 会在开发模式下的控制台输出警告。这些警告会指出哪个 DOM 节点发生了不匹配。

仔细阅读警告信息：它通常会告诉你哪个元素预期是什么，实际渲染是什么。
比较服务器和客户端渲染的 HTML：在浏览器开发者工具中，检查服务器返回的 HTML 和客户端渲染后的 DOM 结构，找出差异。
条件断点：在 ReactDOM.hydrateRoot 或 hydrate 调用前设置断点，逐步调试组件的渲染过程。

八、常见问题与挑战

尽管 SSR 带来了诸多好处，但在实际应用中，它也伴随着一系列挑战。

环境差异：服务器端（Node.js）和客户端（浏览器）的运行环境差异巨大。在服务器端，没有 window、document、localStorage 等浏览器 API。编写同构代码（Isomorphic Code）需要特别注意这些差异。
数据预取复杂性：在服务器端渲染之前，需要预取所有组件所需的数据。这通常意味着需要在路由或组件层级定义数据加载逻辑，并等待所有异步请求完成后才能进行渲染。
构建配置复杂性：需要为服务器端和客户端分别配置 Webpack 或 Rollup 打包，处理 Babel 编译、CSS 导入、图片资源等。
服务器负载：每次用户请求页面，服务器都需要执行 React 应用的渲染逻辑，这会消耗 CPU 和内存资源。在高并发场景下，可能需要优化服务器性能、使用缓存或增加服务器数量。
内存泄漏：在服务器端，每次请求都会创建一个新的 React 应用实例和状态管理实例。如果不正确地清理这些实例，可能导致内存泄漏。确保在每次请求结束时销毁不必要的资源。
第三方库兼容性：许多第三方 React 库最初是为客户端渲染设计的，可能不兼容 SSR。它们可能在初始化时依赖 window 或 document。需要检查库的文档或寻找 SSR 友好的替代品。

九、展望未来：选择性注水与流式 SSR

React 18 及其引入的并发特性，特别是 renderToPipeableStream 和 hydrateRoot，为 SSR 的未来描绘了激动人心的蓝图。

更快的首次内容绘制 (FCP)：通过流式 SSR，浏览器可以更早地接收到 HTML 内容并开始渲染，而不是等待整个页面渲染完成。
更快的可交互时间 (TTI)：选择性注水允许 React 优先处理用户交互的区域，即使页面的其他部分仍在注水过程中。这意味着用户可以更快地与页面进行互动，而不是等待整个页面变得可交互。
更好的用户体验：结合 Suspense，可以实现优雅的加载状态和错误边界，避免了页面加载时的空白或闪烁。当异步数据尚未加载完成时，用户会看到一个回退 UI，一旦数据可用，真正的 UI 就会无缝替换。
更细粒度的控制：开发者可以更精确地控制哪些部分需要立即注水，哪些可以延迟，从而更好地平衡性能和交互性。

这些进步使得 React SSR 更加强大、灵活和高效，能够构建出既具备出色性能又拥有丰富交互性的现代化 Web 应用。

十、结语

“脱水”与“注水”是 React SSR 的核心所在，它们是连接静态预渲染内容与动态交互应用的桥梁。深入理解这两个过程，以及 React 18 带来的最新优化，能够帮助我们构建出性能卓越、用户体验流畅的 React 应用。掌握这些复杂性，并运用最佳实践，将使你的应用在现代 Web 竞争中脱颖而出。

一、 引言：SSR 的魅力与挑战