React Server Components (RSC) 原理：服务器端生成的序列化数据流对客户端体积的缩减 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同学，大家好！把手机静音，把键盘敲得响一点，咱们今天不聊虚的，咱们来聊聊怎么让你的 React 应用“瘦下来”。

我知道，你们现在的情况是什么？打开一个 React 页面，那个转圈圈的 Loading 动画转得比你们老板画的大饼还要圆。你以为你在等数据，其实你在等那个 5MB 的 JS 包下载完。等到页面终于渲染出来，你的浏览器已经累得像只刚跑完马拉松的哈士奇，内存占用飙到 200MB，点个按钮还得再等一秒。

这就是经典的“客户端渲染”带来的痛苦。今天，我们要聊的主角是那个传说中的“救世主”——React Server Components（RSC，服务器端组件）。咱们不讲那些教科书上干巴巴的定义，咱们用最通俗、最幽默，甚至带点“代码味儿”的方式，把这玩意儿的原理扒个底朝天，特别是它是怎么把那一堆臃肿的 JS 压缩成几 KB 的 JSON 的。

准备好了吗？Let’s rock！

第一部分：React 的“肥胖”危机与“外卖”哲学

首先，咱们得搞清楚以前 React 是怎么“干饭”的。

在传统的 CSR（Client-Side Rendering）模式下，React 就像是一个只会做“半成品”的厨师。你给服务器发个请求，服务器回给你一个空荡荡的 HTML 框架，然后给你扔过去一个 5MB 的压缩包（JS Bundle），里面装着所有的 React 代码、所有的逻辑、所有的 UI 组件。

你的浏览器收到这个包，开始下载、解析、执行。这时候，用户看到的就是一片空白，只有那个令人抓狂的转圈圈。等 JS 执行完了，React 才开始把那些半成品“组装”起来，最后给你展示出一张漂亮的图片。

这就像什么？这就像你点了一份麻辣小龙虾外卖。

你打开盒子一看，里面只有一堆带壳的生虾（空白的 HTML），然后你还得自己把虾剥了、煮了、调味（下载并执行 JS）。你累得满头大汗，还没吃上肉呢。

而 React Server Components 是什么？它是“成品外卖”。

服务器端组件（RSC）直接在服务器上把虾剥好了、煮好了、装在盒子里了。服务器直接给你吐出来一份热腾腾的、可以直接吃的熟虾（HTML + 序列化数据）。你拿到手，只要稍微热一下（Hydration，水合），甚至直接就能吃。

核心区别在于：

CSR： 服务器给你代码，让你自己算出结果。
RSC： 服务器算出结果，只给你数据（和 HTML）。

那么，服务器怎么把结果给你呢？它不能直接把对象扔过来，那不安全，也不可控。它得把 React 组件的状态“翻译”成一种服务器和客户端都能读懂的通用语言——序列化。

第二部分：序列化，不仅仅是 JSON

这是 RSC 的灵魂。如果你以为 RSC 只是把 React 组件转成 JSON，那你可就大错特错了。那太简单了，也太慢了。

在 RSC 之前，我们用 JSON.stringify 把数据传给客户端。这玩意儿有个毛病：它不认识 React 的东西。它不认识 useState，不认识 useEffect，甚至不认识 div。它只知道字符串、数字、布尔值、数组和对象。

但是 React 组件里充满了这些东西。比如：

// 这是一个典型的 React 组件
function UserProfile({ user }) {
  const [isFollowing, setIsFollowing] = useState(false);

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
      <button onClick={() => setIsFollowing(!isFollowing)}>
        {isFollowing ? "已关注" : "关注"}
      </button>
    </div>
  );
}

如果服务器直接用 JSON.stringify，它会报错。它不知道怎么序列化 useState（这是个函数），也不知道怎么序列化 <button onClick={...}>（这是个标签）。

所以，React 发明了一种“React 序列化协议”。这东西看起来像 JSON，但它比 JSON 更聪明，也更复杂。

1. ReactNode 的魔法

在 React 内部，所有的东西都被抽象成了 ReactNode 类型。这个类型定义非常宽泛，它包含了：

基本类型： string, number, boolean, null, undefined。
React 元素： <div>, <span>, <MyComponent />。
可渲染对象： Promise, Array, Portal。

当你把一个 React 组件传给 renderToString 或者 renderToPipeableStream 时，React 内部其实是在构建一棵虚拟 DOM 树，但这棵树不是给浏览器看的，它是给传输协议看的。

2. 序列化的“潜规则”

当 React 把这个树序列化成字符串流时，它不会傻乎乎地保留所有的代码逻辑。它会做以下几件事：

剥离函数： useState, useEffect, onClick 这些函数，统统不要。它们是客户端的私有财产，服务器根本不认识。
扁平化结构： 它不会把组件的逻辑代码发过去，它只发“结构”和“数据”。
插入标记： 它会插入一些特殊的标记（比如 $$typeof），告诉客户端：“嘿，这个 div 是一个 React 元素，不是普通的字符串。”

代码演示：手动序列化

为了让大家看透本质，咱们不写 React 代码，咱们写个伪代码来模拟这个过程。

假设我们在服务器端有一个对象，它是 React 组件的渲染结果：

// 服务器端生成的“虚拟 DOM”结构
const serverSideVdom = {
  $$typeof: Symbol.for('react.element'), // React 的身份认证码
  type: 'div',
  key: null,
  props: {
    children: [
      {
        $$typeof: Symbol.for('react.element'),
        type: 'h1',
        props: {
          children: 'Hello, RSC!' // 这里的 'Hello, RSC!' 是字符串，可以直接序列化
        }
      },
      {
        $$typeof: Symbol.for('react.element'),
        type: 'button',
        props: {
          children: 'Click me',
          onClick: () => { console.log('Clicked!') } // 这是一个函数！
        }
      }
    ]
  }
};

如果用普通的 JSON.stringify，这玩意儿会直接炸掉，因为 Symbol 和 Function 都不能被序列化。

RSC 的序列化器会怎么做？

function rscSerialize(node) {
  // 1. 如果是字符串或数字，直接扔进去
  if (typeof node === 'string' || typeof node === 'number') {
    return node;
  }

  // 2. 如果是 null 或 undefined，直接扔进去
  if (node === null || node === undefined) {
    return node;
  }

  // 3. 如果是 React 元素（$$typeof 标记存在）
  if (node.$$typeof === Symbol.for('react.element')) {
    // 哇，这是一个组件！
    // 我们要构建一个特殊的 JSON 格式，比如 { r: 'div', c: [...] }
    // 注意：这里绝对不能包含 onClick 这种函数！

    const serializedChildren = node.props.children.map(child => rscSerialize(child));

    return {
      r: node.type, // 'div', 'h1', 或者组件的名称
      c: serializedChildren
    };
  }

  // 4. 如果是数组，递归处理
  if (Array.isArray(node)) {
    return node.map(item => rscSerialize(item));
  }

  return node;
}

// 运行序列化
const result = rscSerialize(serverSideVdom);

console.log(result);

看，这就是 RSC 序列化的本质。它把一个复杂的、包含逻辑的 React 树，剥离了所有“动脑子”的东西（函数、钩子），只保留了“长相”（HTML 标签）和“血肉”（数据）。

这就是为什么体积小！ 因为服务器只发给你“长相”和“血肉”，没发给你“脑子”。

第三部分：流式传输，像水管一样出水

光有序列化还不够，如果数据太大了，传输起来还是慢。这时候，React 引入了流式传输（Streaming）。

想象一下，你正在煮一锅粥。如果等粥完全煮好了再端上桌，你可能饿死了。RSC 的流式传输就像是用一根水管往碗里倒粥。你不需要等整个页面生成完毕，只要生成了一部分（比如 HTML 头部和标题），就可以立刻发给浏览器开始渲染了。

客户端拿到这部分数据，立刻渲染到屏幕上。剩下的部分边传边渲染。用户感觉不到延迟，页面瞬间就“活”了。

代码演示：Node.js 中的流式渲染

在 Next.js 或者 React 18 的服务器端，你会用到类似这样的代码：

import { renderToPipeableStream } from 'react-dom/server';
import App from './App';

// 启动一个流
const stream = renderToPipeableStream(<App />);

// 监听进度
stream.pipe(res);

// 处理错误
stream.on('error', (error) => {
  console.error(error);
  res.statusCode = 500;
  res.end('Internal Server Error');
});

这个 res 是什么？它是 HTTP 响应流。renderToPipeableStream 会一边生成 React 的虚拟 DOM，一边把它转换成 HTML 字符串，直接通过管道扔给网络。

对于客户端来说，它接收到的不是一大块 JSON，而是一段一段的 HTML 片段。React 客户端会维护一个“待水合”的树，每当收到新的数据，就把它挂载到页面上。

这就解释了为什么 RSC 能做到“首屏渲染极快”： 因为它不需要等待所有组件都计算完，也不需要下载完所有的 JS，它直接把 HTML 写进去了。

第四部分：客户端的水合——给空壳子装上灵魂

好，现在服务器把 HTML 和序列化的数据流发过来了。浏览器拿到了一堆 HTML 标签和一堆 JSON 数据。

这时候，你打开开发者工具，你会发现页面上是有内容的。但是，如果你试着点击那个“关注”按钮，或者输入文字，你会发现没反应。

为什么？因为这时候的页面只是个“空壳子”。React 的逻辑代码还没加载呢！

这就需要水合（Hydration）。

水合的过程，就像是把乐高积木的说明书递给你。服务器给你发了一堆已经拼好的乐高模型的照片（HTML），然后你拿着说明书（客户端代码），把那些积木和你脑子里的逻辑对应起来。

React 客户端会拿着服务器发来的序列化数据，重新构建一棵虚拟 DOM 树。它会对比浏览器里现有的 DOM 节点，看看它们是不是匹配。

匹配成功： 保留现有 DOM，赋予其交互能力（绑定事件监听器）。
不匹配： 可能是浏览器做了预渲染，或者数据有差异，React 会根据差异去更新 DOM。

代码演示：客户端接收数据

在 React 18 的客户端代码中，虽然我们通常不直接处理序列化数据，但我们可以看看它是怎么工作的：

'use client'; // 告诉 React：这玩意儿要在客户端跑

import { useState, useEffect } from 'react';

function UserProfile() {
  const [data, setData] = useState(null);

  // 这里其实是由 React 自动完成的，不需要我们手动 fetch
  // React 会把服务器传来的序列化数据自动“反序列化”并填充到组件中

  useEffect(() => {
    // 模拟接收到服务器数据的过程
    // 实际上这是由 React 内部自动处理的，数据可能来自 Suspense、fetch 等

    // 假设我们拿到了服务器序列化后的对象
    const serializedData = {
      r: 'div',
      c: [
        { r: 'h1', c: 'Hello, RSC!' },
        { r: 'button', c: 'Click me' } // 注意：这里没有 onClick 函数！
      ]
    };

    // React 内部会将这个对象转换回 ReactElement
    // 并触发重新渲染

    console.log("Data received:", serializedData);
  }, []);

  return (
    <div>
      {data ? (
        // 这里的渲染是直接基于 data 的
        <div>{/* 渲染逻辑 */}</div>
      ) : (
        <p>Loading...</p>
      )}
    </div>
  );
}

重点来了： 你看，客户端组件接收到的是一个静态对象。它没有 onClick 这个函数。这个函数是从哪里来的？

是从客户端的代码里来的！

当 React 完成水合后，它会检查这个 button 组件。它发现这个组件的 type 是 'button'，而且它对应着客户端代码里的 button 标签。于是，React 会自动把你在客户端写的 onClick 事件绑定上去。

这就是 RSC 的精妙之处：

服务器只负责生成静态数据和 HTML，不包含交互逻辑。所以体积极小。
客户端只负责加载必要的交互逻辑（JS Bundle），然后把逻辑“套”在服务器生成的静态结构上。

第五部分：体积缩减的终极奥义——对比实验

咱们来做个思想实验，算算账。

假设你要展示一个用户列表，每个用户有头像、名字、简介。

方案 A：传统 CSR

服务器端： 查询数据库，生成一个用户对象数组。
传输： 服务器把这个数组转成 JSON，发回给客户端。假设数据量是 10KB。
客户端： 下载 React 库（3MB），下载你的业务代码（500KB）。
执行： React 在浏览器里遍历这个数组，生成 10 个 <div>，渲染出 UI。

体积： 3MB + 500KB + 10KB = 3.51MB。
体验： 白屏时间长，数据来了再渲染。

方案 B：RSC

服务器端： 查询数据库，生成用户对象数组。然后，React 在服务器端直接把数组渲染成了 HTML 字符串。
- 注意： 服务器不需要把 <div class="user">...</div> 这种字符串发过来，那太重了。
- 服务器生成的是类似这样的结构：
```
[
  { "id": 1, "name": "Alice", "bio": "..." },
  { "id": 2, "name": "Bob", "bio": "..." }
]
```
- 等等，这好像和 CSR 一样？不对！
- 在 RSC 里，服务器生成的这个 JSON 是嵌套在 HTML 结构里的。而且，React 序列化器会把这个数组扁平化，直接作为 HTML 的子节点发送。
传输： 服务器直接把 HTML 字符串 + 扁平化的数据流发回给客户端。假设最终传输体积是 5KB（HTML 结构 + 数据）。
客户端： 下载 React 库（3MB），下载交互逻辑（比如“点击头像显示详情”的代码，100KB）。
执行： React 收到 5KB 的流，解析 HTML，匹配数据，水合。

体积： 3MB + 100KB + 5KB = 3.105MB。

等等，这不还是 3MB 吗？

没错！RSC 并不是要减少 React 核心库的大小（那是不可能的，React 核心库本身就是用 C++ 写的，体积已经优化到了极致）。RSC 的真正优势在于业务代码体积的缩减。

在 CSR 里，你需要把所有的 UI 组件都打包成 JS。在 RSC 里，只有需要交互的部分才需要打包成 JS。

比如上面的用户列表，展示名字和简介，这部分是纯静态的，不需要交互，所以这部分不需要下载任何 JS 代码。

只有当你点击头像，想要弹出详情框时，React 才会去加载那 100KB 的交互代码。

结论：
如果你的页面 80% 都是静态内容（博客文章、新闻列表、产品展示），RSC 能帮你砍掉 80% 的 JS 体积。

第六部分：内存的博弈——服务器的内存 vs 客户端的内存

聊完了体积，咱们聊聊内存。RSC 把计算压力从客户端移到了服务器。

以前（CSR）：

浏览器内存： 需要加载 React 运行时、虚拟 DOM 树、状态管理库。如果页面很复杂，浏览器内存会飙升。
服务器内存： 负担很轻，只负责查数据库。

现在（RSC）：

浏览器内存： 极轻。因为它只加载了必要的交互代码。
服务器内存： 负担很重。它需要运行 React，维护虚拟 DOM 树，计算序列化数据。

这带来了一个新问题： 如果你的页面非常复杂，比如一个 3D 的电商展示页，服务器需要渲染一棵巨大的树，序列化也需要消耗大量内存。如果几百个用户同时访问，服务器可能会因为内存溢出（OOM）而挂掉。

所以，RSC 的最佳实践是：服务器负责静态内容，客户端负责复杂交互。

这就是为什么有了 use client 指令。

第七部分：`use client` —— 指挥棒

在 React 18 之前，默认就是客户端渲染。现在，默认是服务器端渲染。

如果你想让某个组件在服务器上运行，你就不用写任何指令。如果你想让某个组件在客户端运行（比如需要 useState, useEffect, window 对象，或者 onClick），你就得在文件顶部加一行：

'use client';

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

这就好比给那个组件发了张“通行证”，告诉 React 序列化器：“嘿，别把这个组件的数据发到客户端，留着自己用吧，客户端会自己处理。”

代码演示：混合模式

// components/UserList.tsx (默认是 Server Component)
async function UserList() {
  const users = await fetch('https://api.example.com/users').then(res => res.json());

  return (
    <ul>
      {users.map(user => (
        // 这里直接把 user 对象传给子组件
        // 注意：这里不能直接用 useState，因为这是服务器组件
        <li key={user.id}>
          <UserCard user={user} />
        </li>
      ))}
    </ul>
  );
}

// components/UserCard.tsx (默认是 Server Component)
function UserCard({ user }) {
  return <div>{user.name}</div>;
}

// components/UserAction.tsx (需要交互，变成 Client Component)
'use client';

import { useState } from 'react';

function UserAction({ userId }) {
  const [isFollowing, setIsFollowing] = useState(false);

  return (
    <button onClick={() => setIsFollowing(!isFollowing)}>
      {isFollowing ? '已关注' : '关注'}
    </button>
  );
}

在这个例子中：

UserList 和 UserCard 在服务器端渲染。它们的体积会被压缩成极小的序列化数据。
UserAction 在客户端运行。它下载了必要的 JS 代码来实现点击功能。

React 会自动地把这三个组件串联起来。UserList 发送数据给 UserCard，UserCard 发送 userId 给 UserAction。整个过程对用户来说是透明的。

第八部分：进阶技巧——序列化的边界

虽然 RSC 很强大，但它不是万能的。序列化是有“边界”的。

1. 循环引用

在 JavaScript 中，对象是可以循环引用的。但是在 JSON 中，这是不合法的。RSC 的序列化器非常聪明，它会处理这种情况，通常会把循环引用转为 null 或者特殊的标记。

2. 不可序列化的对象

如果你在组件里返回了一个 Date 对象，或者一个包含了 Map、Set 的对象，React 序列化器会尝试把它们转成普通对象。如果转不了，就会报错。

// 服务器端组件
async function ServerComponent() {
  const map = new Map([['a', 1], ['b', 2]]);

  return <div>{map}</div>; // React 会尝试序列化 map，可能会失败或者丢失数据
}

3. 闭包陷阱

因为服务器组件的数据是直接传给客户端组件的，如果你在服务器组件里定义了一个函数，然后把函数传给客户端组件，这个函数会被序列化吗？不会。

序列化器非常严格，它只序列化数据。如果你传了一个函数，它会被忽略。

// Server Component
async function ServerComp() {
  const handleClick = () => console.log('Clicked'); // 这个函数在服务器上

  return <ClientComp onClick={handleClick} />; // React 序列化器会直接扔掉 onClick
}

// Client Component
'use client';
function ClientComp({ onClick }) {
  // onClick 永远是 undefined！
  return <button onClick={onClick}>Click me</button>;
}

这就是为什么我们通常不直接在服务器组件里写逻辑，而是通过 props 传数据给客户端组件，让客户端组件自己处理逻辑。

第九部分：总结——RSC 的未来

好了，咱们今天聊了这么多。

React Server Components 的核心原理就是：利用服务器强大的计算能力，生成极致轻量的数据流，传输给客户端，再由客户端用极小的体积代码进行水合。

它把“UI 生成”和“UI 交互”这两件事彻底分开了。

服务器： 负责算。算出数据，算出 HTML，算出结构。
客户端： 负责玩。玩转交互，玩转动画，玩转状态。

它不仅仅是体积的缩减，更是架构的变革。它让我们从“打包代码”的思维转向了“传输数据”的思维。

当然，它也带来了新的挑战，比如服务器的内存压力、序列化的复杂性、调试的困难度。但不可否认的是，它是目前解决前端性能瓶颈的最强方案之一。

最后，送大家一句话：

不要试图把整个大脑都塞进这个网页里，服务器的大脑够用了，你只需要留一点空间给手指头去点那个“点赞”按钮。

谢谢大家！下课！