各位好，把你们的咖啡拿好，把那些“Hello World”的陈词滥调扔进垃圾桶。今天我们不聊怎么写一个 useEffect，也不聊怎么把 Tailwind 搞得花里胡哨。今天，我们要像手术刀一样切开 React 的肚子，看看当它在服务器上分娩出 HTML 时，肚子里到底藏了什么。
特别是，我们要聊聊那个神秘的“脱水”过程。你们大概见过这样的代码：
// 在你的组件里
function App() {
return <div className="secret">I am a hidden script</div>
}然后浏览器里多了一个 <div>。但这只是冰山一角。真正的高手都知道，React 在生成这个 HTML 的过程中，其实偷偷地把整个 Fiber 树的状态打包成了一坨 JSON，塞进了 HTML 里的 <script> 标签里。这就像是魔术师把鸽子变没时，其实手里攥着一只备用鸽子。
今天，我们就来揭秘这个魔术。
第一部分：HTML 的悲剧——它是个哑巴
首先，我们要明白一个残酷的事实：HTML 是个哑巴。
当你写 <button>Click Me</button> 时，HTML 标准里压根就没有“点击”这个概念。HTML 只是一堆静态的文本节点、元素和属性。它不知道 onClick，不知道 useState，甚至不知道自己是不是一个“按钮”。
React 是个强迫症患者。它喜欢控制一切。当服务器渲染（SSR）发生时，React 必须把它的内心世界——也就是那棵复杂的 Fiber 树——翻译成 HTML 这种哑巴语言。
翻译的过程，就是“脱水”。脱水意味着什么？意味着把 React 的内部状态（对象、函数引用、闭包）剥离，只剩下能在浏览器里运行的静态数据（字符串、数字、布尔值）。
如果 React 只是生成普通的 HTML，那么客户端水合（Hydration）就会变成一场灾难。想象一下，你把一个活人（React 实例）扔到一个只有骨架（HTML）的房间里。React 进去后，面对着一堆不知道是 div 还是 span 的节点，完全不知道该干什么。
所以，React 必须把它的记忆带上。怎么带？通过序列化。
第二部分：Fiber 树——React 的神经中枢
在深入序列化之前，我们必须得聊聊 Fiber。Fiber 不是 React 的织物，它是 React 的调度器，是它的神经中枢。
每一个 React 组件，在内存中都是一个 Fiber 节点。它的结构大概长这样（为了方便理解，简化版）：
interface Fiber {
tag: number; // 节点的类型：函数组件、类组件、DOM节点等
type: any; // 组件的类型或标签名
key: string | null; // 唯一标识
props: { // 节点的属性
children: any,
// ... 其他属性
};
return: Fiber | null; // 父节点
child: Fiber | null; // 第一个子节点
sibling: Fiber | null; // 下一个兄弟节点
stateNode: any; // DOM 节点引用（如果是DOM节点）
}这是一个树形结构。React 的渲染过程，本质上就是在这个树里递归遍历。
现在，问题来了：我们要把这个树变成字符串（HTML）。字符串是线性的，树是分形的。我们怎么把树压扁成线性的 HTML？
第三部分：序列化算法——把树压扁的魔法
React 内部有一个序列化函数（通常在 ReactFiberReconciler 或相关模块中）。它的核心逻辑非常简单，就是递归。
想象一下，你有一个文件夹，里面全是文件和子文件夹。你要把它们打印出来。你不会一次性打印所有内容，你会先打印根目录，然后进入第一个子文件夹，打印里面的内容，再回到根目录打印第二个子文件夹。
React 的序列化器就是这么干的。
1. 标签的映射
首先，它看 Fiber.type。如果是 div，它就输出 <div>。如果是 MyComponent，它就输出 <MyComponent />。
2. 属性的清洗
这是最有趣的部分。Fiber 节点的 props 里有很多 React 专用的东西，这些东西 HTML 可不懂。
// Fiber 里的 props
{
children: [...],
onClick: () => console.log('hi'), // 这个函数，HTML 懂吗？不懂！
'data-reactroot': true, // 这个属性，HTML 需要吗？不需要！
// ...
}序列化器会执行一个“过滤”操作。它会把 onClick 这种函数扔掉，把 data-reactroot 这种调试属性扔掉。它会保留 className（HTML 是 class，React 是 className，序列化器负责翻译），保留 id，保留 style。
3. 子节点的处理
这是序列化的核心难点。React 把 children 当作一个特殊的属性。在 Fiber 里，props.children 通常是一个数组或者一个单一节点。
但在序列化时，React 会把 children 展开。它会遍历 Fiber.child，把每个子节点转换成字符串，然后拼接到父节点的 HTML 末尾。
function serializeFiber(fiber) {
// 1. 获取标签名
const type = fiber.type;
const tag = fiber.tag;
// 2. 处理特殊类型（如 Fragment, Portal）
if (tag === 0) return '';
// 3. 构建 HTML 开始标签
let html = `<${type}`;
// 4. 遍历 props，过滤掉 children
for (const key in fiber.props) {
if (key === 'children') continue; // 孩子们自己处理
if (key === 'key') continue; // key 不出现在 HTML 属性里
if (key === 'ref') continue; // ref 也不需要
if (typeof fiber.props[key] === 'function') continue; // 函数属性扔掉
html += ` ${key}="${fiber.props[key]}"`;
}
// 5. 处理 children
html += '>';
// 递归处理子节点
let currentChild = fiber.child;
while (currentChild) {
html += serializeFiber(currentChild);
currentChild = currentChild.sibling;
}
// 6. 关闭标签
html += `</${type}>`;
return html;
}这就是 React 把复杂对象变成 HTML 字符串的底层逻辑。它像剥洋葱一样，一层一层剥开 Fiber 节点，吐出 HTML 字符串。
第四部分：隐藏的脚本块——Next.js 的把戏
刚才我们说的是“标准”的 React SSR。标准 React 其实并不把 Fiber 序列化成 JSON 脚本块。标准 React 只是把 Fiber 转换成 HTML 字符串流，然后扔给浏览器。
但是，你们在 Next.js 或者一些 SSR 框架里看到的 __NEXT_DATA__ 脚本块是怎么回事？那是怎么来的？
这其实是 React 生态圈的一个“补丁”，或者说是一种高级用法。虽然 React 核心库不直接干这事，但 Next.js 的 SSR 流程里，确实有一段逻辑会抓取 React 渲染出来的 Fiber 树，然后把它序列化成 JSON，塞进 <script id="__NEXT_DATA__"> 里。
为什么这么做？为了更精准的水合。
普通的 HTML 水合是“尽力而为”。React 会解析 HTML，然后试图匹配 DOM。如果 HTML 里的 class 名变了，或者顺序变了，React 会报错：“Hydration failed because the initial UI does not match what was rendered on the server”。
但是，如果你在 HTML 里塞了一个 JSON 脚本块，告诉 React：“嘿，服务器上的确切顺序是 [A, B, C]”，React 就可以精准地重建树结构，而不是傻傻地去 DOM 里找。
让我们看看 Next.js 的 __NEXT_DATA__ 到底长什么样。当你访问一个 Next.js 页面时，源码里大概会有这样一段 JSON：
{
"pageProps": {
"message": "Hello from server"
},
"query": {},
"buildId": "development",
"nextLocale": "en",
"nextI18n": {
"defaultLocale": "en",
"locales": ["en"]
},
"locale": "en",
"locales": ["en"],
"isFallback": false,
"gssp": true,
"appGip": true,
"scriptLoader": []
}这看起来像普通的 JSON。但如果你看 React 组件的 children，Next.js 会把整个组件树的结构序列化进去。
{
"__NEXT_DATA__": {
"props": {
"pageProps": {
"count": 42
}
},
"children": {
"type": "div",
"props": {
"className": "container",
"children": [
{
"type": "h1",
"props": {
"children": "Server Rendered Title"
}
},
{
"type": "button",
"props": {
"children": "Increment",
"onClick": "console.log('clicked')" // 注意，这里有时候会被序列化成字符串
}
}
]
}
},
// ...
}
}注意看 children。它是一个嵌套的 JSON 对象，结构完全复制了 Fiber 树。这就是“隐藏脚本块”的真相。
第五部分：反序列化与水合——复活僵尸
现在，服务器端已经把 Fiber 变成了 HTML，甚至可能变为了 JSON 脚本块。接下来是客户端。
客户端的 hydrateRoot 或者 ReactDOM.hydrate 会做什么？
- 解析脚本块：首先，它会去 DOM 里找那个隐藏的
<script>标签（通常是__NEXT_DATA__）。 - 解析 JSON：把它解析成 JavaScript 对象。
- 重建 Fiber 树：它拿着这个 JSON 对象，开始执行“反序列化”。它创建新的 Fiber 节点，把 JSON 里的
type、props、children塞回去。 - 匹配 DOM：这是最关键的一步。React 拿着重建的 Fiber 树，去对比浏览器里已经存在的 DOM 节点。
- 如果类型匹配（
div对div），React 会接管这个节点。 - 如果属性匹配（
className对className），React 会保留。 - 如果不匹配，React 会报错，或者（在 18 版本以后）使用
startTransition进行渐进式水合。
- 如果类型匹配（
第六部分：代码实战——我们手写一个序列化器
为了证明我刚才说的都是实话，而不是在吹牛，我们来手写一个极其简陋的 React 序列化器。别指望它能处理所有边缘情况，但原理全在里面。
/**
* 模拟 React Fiber 节点
*/
class FiberNode {
constructor(type, props) {
this.type = type;
this.props = props;
this.child = null;
this.sibling = null;
this.return = null;
}
}
// 构建一个简单的树： <div id="root"><h1>Hello</h1></div>
const rootFiber = new FiberNode('div', {
id: 'root',
children: [
new FiberNode('h1', {
children: 'Hello'
})
]
});
/**
* 序列化函数
*/
function serializeFiberToString(fiber) {
// 如果是 null 或 undefined，返回空
if (!fiber) return '';
// 1. 获取标签名
const type = fiber.type;
// 2. 构建 HTML 开头
let html = `<${type}`;
// 3. 遍历 props，构建属性
for (const key in fiber.props) {
// React 特有属性过滤
if (key === 'children' || key === 'key' || key === 'ref' || key === '__source' || key === '__self') {
continue;
}
// 处理函数属性（这里简单处理，实际 React 会做更复杂的过滤）
if (typeof fiber.props[key] === 'function') {
continue;
}
// 处理 children
if (Array.isArray(fiber.props[key])) {
continue; // children 单独处理
}
html += ` ${key}="${fiber.props[key]}"`;
}
html += '>';
// 4. 递归处理子节点
// React 的 children 通常是一个数组，或者是一个单一的节点
const children = fiber.props.children;
const childArray = Array.isArray(children) ? children : (children ? [children] : []);
for (let i = 0; i < childArray.length; i++) {
html += serializeFiberToString(childArray[i]);
}
// 5. 关闭标签
html += `</${type}>`;
return html;
}
// 运行序列化
const htmlOutput = serializeFiberToString(rootFiber);
console.log(htmlOutput);运行这段代码，你会看到控制台输出：
<div id="root"><h1>Hello</h1></div>看，这就是 React 做的事。它把内存里的对象，变成了字符串。
现在，我们再来看看“JSON 脚本块”的版本。我们写一个函数，把 Fiber 转成 JSON：
function serializeFiberToJSON(fiber, depth = 0) {
if (!fiber) return null;
const result = {
type: fiber.type,
props: {},
children: []
};
// 递归处理 children
const children = fiber.props.children;
const childArray = Array.isArray(children) ? children : (children ? [children] : []);
childArray.forEach(child => {
result.children.push(serializeFiberToJSON(child, depth + 1));
});
// 处理 props
for (const key in fiber.props) {
if (key === 'children' || key === 'key' || key === 'ref') continue;
// 过滤函数
if (typeof fiber.props[key] === 'function') continue;
// 简单的值类型转换
if (typeof fiber.props[key] === 'object') {
// 如果是对象，可能需要特殊处理，这里简化
result.props[key] = JSON.stringify(fiber.props[key]);
} else {
result.props[key] = fiber.props[key];
}
}
return result;
}
const jsonOutput = serializeFiberToJSON(rootFiber);
console.log(JSON.stringify(jsonOutput, null, 2));你会得到这样的 JSON：
{
"type": "div",
"props": {
"id": "root"
},
"children": [
{
"type": "h1",
"props": {},
"children": [
{
"type": "string",
"props": {},
"children": [
"Hello"
]
}
]
}
]
}这就是 Next.js 的 __NEXT_DATA__ 内部逻辑的简化版。只不过 Next.js 做得更复杂，它会把字符串也变成 Fiber 节点，这样整个结构就是完全一致的。
第七部分：那些“坑”——为什么你的水合会失败
既然我们知道了序列化是把 Fiber 变成 HTML/JSON，那么水合失败通常就是“反序列化”失败。
-
顺序问题：
React 的序列化是递归的。先父节点，后子节点，然后是兄弟节点。
如果你在客户端的 JSX 里写<div><span>A</span><span>B</span></div>，但 HTML 里是<div><span>B</span><span>A</span></div>。React 重建树时，发现第一个子节点类型匹配，但内容不对，就会报错。 -
属性大小写：
HTML 属性不区分大小写（class和Class是一样的），但 JavaScript 区分。React 在序列化时会自动把className变成class。如果你在 HTML 里手动写了class="foo"而服务器端生成的是className="foo"，虽然浏览器都能渲染，但 React 的比较逻辑可能会觉得不对劲（取决于具体的比较实现，通常会有容错，但在严格模式下可能会抓狂）。 -
children 的类型：
React 对children的处理非常宽容。它可以是一个字符串，一个数组，或者一个 React 元素。
但是，序列化器必须非常严谨。如果你在 Fiber 里有一个children: "Hello"，序列化出来就是Hello。如果你在 Fiber 里有一个children: [null, "Hello"]，序列化出来就是Hello（null 被吞掉了）。
如果客户端的 DOM 结构和序列化后的结构不一致，React 就会怀疑人生。 -
HTML 实体编码：
React 的序列化器会自动把<转成<，把>转成>。这是为了防止 XSS。但如果你在客户端手动写了 HTML 字符串而没有经过序列化器的转义，React 水合时会发现属性值不匹配。
第八部分：现代 React 的异步水合
到了 React 18，事情变得更复杂了。我们有了 Suspense 和 startTransition。
这意味着，水合不再是一蹴而就的。服务器端渲染出 HTML 后，客户端拿到 HTML，开始水合。但是，如果某些组件还在加载（比如从 API 拉取数据），React 就会暂停水合，展示一个 Loading 状态。
这时候，HTML 里的内容可能是不完整的。
React 是如何处理这种情况的？
它依赖于 Fiber 的状态。在 render 过程中，如果一个组件是“未完成”的，Fiber 节点会被标记。序列化器在生成 HTML 时，会把这个状态标记进去（通常通过 data-react-prefetched 或类似的属性）。
客户端水合时，React 会读取这个标记。如果发现标记说“这部分还没准备好”，React 就不会尝试去匹配 DOM，而是保持原样，等待 use 或 Suspense 的回调触发。
这就解释了为什么有时候你看到一个 Loading 骨架屏，然后它突然跳变成了真实内容。这就是 React 在后台悄悄完成了“反序列化”和水合工作，然后突然把 UI 换了。
第九部分：总结——魔术背后的逻辑
好了，各位，让我们收起惊奇。
React 把 Fiber 状态序列化为 HTML 中的隐藏脚本块，本质上是一个数据序列化与反序列化的过程。
- 序列化：React 遍历 Fiber 树，把对象属性翻译成字符串，把嵌套结构压平成 HTML 标签。在这个过程中，它过滤掉了所有对浏览器无用的信息（函数、闭包、内部状态），只保留了渲染所需的静态数据。
- 传输：这些数据通过 HTTP 响应体发送给浏览器。如果是 Next.js 这种高级玩法，它会额外把结构化的 JSON 打包在
<script>标签里，作为“作弊码”传给客户端。 - 反序列化：客户端 React 拿到 HTML 或 JSON，重新构建 Fiber 树，并与现有的 DOM 节点比对。
这就像是你写了一本小说（React 组件），把它翻译成了外星文字（HTML）。然后你把书寄给了外星人。外星人拿到书后，虽然看不懂外星文字，但他们有字典（React 内部逻辑），能把外星文字还原成你的小说。
如果你在翻译过程中（序列化）漏掉了一个标点符号（属性），或者外星人拿到的书页顺序乱了（HTML 结构不对），那么“还原”过程就会失败，外星人就会尖叫（Hydration Mismatch Error）。
所以，下次当你看到 Hydration failed because the initial UI does not match what was rendered on the server 这个报错时，别慌。去检查你的 HTML 结构，检查你的属性顺序，或者检查一下你是不是在客户端偷偷修改了 DOM。
React 的脱水与水合，就是一场在服务器和浏览器之间进行的精密的数据传递游戏。它让网页不再是静态的死物，而是拥有了服务器赋予的“灵魂”。
现在，拿起你的键盘，去享受这种把大脑里的想法变成屏幕上静态代码的快感吧。别忘了，代码如诗，React 便是那押韵的韵脚。