首页 / 文章 / React服务器组件：零包渲染背后的架构设计

React React Server Components Next.js Web Performance Frontend Architecture

React服务器组件：零包渲染背后的架构设计

理解React服务器组件的设计理念，涵盖包体积与流水线问题、服务器端与客户端边界以及RSC数据负载等内容。

3487 词

如果你花了时间试图理解 React Server Components，结果却比开始时更加困惑，这并不是说明你忽略了什么显而易见的东西，而恰恰表明你所看到的那些解释本身就是问题所在。有几年时间，官方对 Server Components 的定义是“在服务器端渲染的组件”，这个说法听起来与 Next.js 中的 getServerSideProps 或传统服务器端渲染功能极为相似。随后又出现一种说法，称这类组件“不会向客户端发送任何 JavaScript”，这听起来更像是一种性能优化技巧，而非构建应用程序的新方式。直到 App Router 问世后，Next.js 项目中的每个文件默认都变成了 Server Component，除非你在文件顶部添加特定的字符串才能改变这一设置。

这种困惑并非你的失误。它之所以出现，是因为人们试图用旧范式的词汇来描述一种真正全新的理念。本指南旨在填补这一空白。读完之后，你不仅会了解 Server Components 的运作机制，还会明白为何它们能带来一种完全不同的 React 应用程序思维方式。

RSC 实际解决的问题

在探讨 Server Components 的工作原理之前，先了解是什么促使 React 创造出它们会更有帮助。问题从来不是服务器端渲染的速度太慢，真正的问题是 React 的组件模型建立在“所有操作都在浏览器中完成”这一假设之上，即便这种假设会带来不必要的开销。

包体积的困扰

In the classic React model, every component you author turns into JavaScript that gets shipped to the browser, no exceptions. It makes no difference whether that component just renders some static markdown, does a simple date calculation, or hits a database. As long as it lives somewhere in your component tree, its code lives in your bundle too.

That creates an unforgiving trade-off. Adding more components inflates your JavaScript payload. A heavier payload pushes out your Time to Interactive. In practice, you end up delivering code to browsers that never had any reason to execute it.

The Waterfall Problem

在 Server Components 出现之前，任何需要数据的组件都必须在数据到达客户端后才能获取它。典型的处理方式是先渲染一个占位符外壳，启动 useEffect，等待响应，之后才渲染实际内容。如果该内容包含需要自身数据的嵌套组件，同样的流程会重复：又一个效应被触发，又一次等待，延迟不断叠加。这种连锁反应就是数据获取的瀑布流模式，这也解释了为何即便后端 API 的响应速度很快，许多 React 应用依然显得缓慢。

一种解决办法是使用 getServerSideProps 或路由加载器等工具将数据获取操作提升到路由层面，但这样做有个弊端：它会破坏组件的独立性。页面突然不得不了解那些从概念上应属于其子组件的数据，组件也不再是独立的单元。

水合开销

传统的服务器端渲染方式是在服务器上生成HTML并发送到客户端，然后在客户端通过JavaScript重新渲染整个应用以实现交互功能。这意味着每一个组件，包括那些根本不需要任何客户端行为的组件，都不得不经历水合过程。实际上，即便是完全静态的内容，也要付出实现交互功能的成本。

React Server Components从架构层面解决了这三个问题，而非作为简单的性能优化补丁。

核心概念：Server Components并非“SSR 2.0”

整个指南所基于的核心思想是：Server Components并非用于渲染页面的工具，而是一种独立的组件类别。

传统的React仅认可一种组件——在浏览器中运行的组件。这类组件可以持有状态、执行副作用操作并响应事件，其从创建到销毁的整个生命周期都在客户端完成。

React Server Components增加了第二种组件类型。服务器组件在服务器端执行，它可以自由地操作文件系统、直接查询数据库，或引入仅在Node.js环境中运行的库。但它无法使用useState、useEffect或添加事件处理程序，因为它根本不会在浏览器中运行，也没有对应的hydration步骤，其代码甚至不会以JavaScript的形式传输到客户端。

一个有助于理解的方式是：现在的React组件树是复合型的，某些分支在服务器端生成，而其他分支则在浏览器中生成。服务器端的分支仅在请求过程中渲染一次，其生成的内容会以序列化的React元素形式传输到客户端。客户端的分支则像往常一样在浏览器中渲染，保留着你所熟悉的全部交互功能。

这与SSR的机制不同。服务器端渲染会在服务器上将整个应用转换为HTML，之后再在浏览器中重新加载该内容。而RSC则只在服务器上渲染特定组件，根本不会将其底层代码传输到浏览器中。

实际发送给客户端的内容是什么

服务器组件在渲染时不会输出HTML，而是生成其输出的序列化描述，即RSC Payload——这是一组类似JSON的指令流，用于告诉客户端的React如何构建所需显示的组件结构。

当请求包含服务器组件的页面时，后台发生的事件顺序如下：

React在服务器上渲染这些服务器组件。

对于每个服务器端组件，它会输出实际渲染后的结果——即生成的元素，而非生成这些元素的源代码。

而对于每个客户端组件，它则输出一个引用：一个标记指示该组件应挂载的位置，以及它所需的属性。

服务器会将整个数据包流式传输到浏览器中。

浏览器的 React 运行时会解析该数据包并构建出对应的组件树结构。

客户端组件随后会下载自己的代码并进行水合处理；而已经渲染完成的服务器端组件则完全不需要进行水合步骤。

关键在于，服务器端组件代码永远不会被打包进发送到浏览器的 JavaScript 文件中。想象一下，有一个基于 200KB 大小的 markdown 解析库构建的 MarkdownRenderer 组件。如果该组件是服务器端组件，那么整个 200KB 的库都会留在服务器上。浏览器只能看到解析器生成的最终结构，而无法见到解析器本身。

这就是“零打包体积”这一说法的实质，它并非某种简单的优化技巧，而是真正改变了构建 React 应用程序的方式。

服务器端与客户端之间的界限

在 App Router 中，除非另有说明，每个文件都被视为服务器组件。这并非仅仅是风格上的默认设置，而是框架中固有的结构假设，体现了大部分界面元素其实根本无需在浏览器中运行这一理念。

相比之下，客户端组件则是旨在在用户设备上执行的代码。要将其标记为客户端组件，需在文件顶部添加 "use client" 指令。这并非单纯的提示性文字，而是一个明确的界限标志。它告知 React 编译器：该文件中定义的所有内容以及通过导入引入的任何资源，都必须被打包并传输到浏览器中。

维持整个系统一致性的规则是：服务器组件可以自由导入并渲染客户端组件，但反之则绝不允许——客户端组件无法导入服务器组件。

乍看之下这似乎有悖常理。难道服务器端代码不应该在任何地方都能使用，包括客户端文件中吗？其实并非如此，只要了解数据的实际传输流程就会明白：

首先执行的是服务器组件，它可以直接访问数据库和后端资源。它会获取所需数据并构建布局。在该布局中，它可能会渲染类似 <UserProfile /> 的内容，而这类内容需要交互功能，因此这部分会被编写为客户端组件。父服务器组件会将获取到的用户数据以属性的形式传递下去。

客户端组件仅使用这些属性来渲染交互部分。它无法反向调用并导入服务器组件，因为在浏览器中运行时，服务器端的处理早已完成，没有剩余的服务器进程可供调用。

这就是为什么这种架构行不通的原因：

// ❌ Impossible: Client Component importing Server Component
'use client';
import { ServerDataFetcher } from './ServerDataFetcher'; // This breaks!
export function ClientWidget() {
  return (
    <div>
      <ServerDataFetcher /> {/* Cannot render a server component here */}
    </div>
  );
}

但采用另一种结构则是完全可行的：

// ✅ Correct: Server Component importing Client Component
// This is a Server Component (no 'use client')
import { ClientWidget } from './ClientWidget';
async function ServerDataFetcher() {
  const data = await db.query('SELECT * FROM posts');

  return (
    <div>
      <h1>Latest Posts</h1>
      {data.map(post => (
        <ClientWidget key={post.id} post={post} />
      ))}
    </div>
  );
}

其模式很简单：服务器组件负责数据获取和整体结构渲染，然后将数据传递给位于树结构的末端节点的交互组件。这些末端组件负责处理点击、表单提交和动画效果。这样的架构本质上就是在服务器端渲染的树结构，仅在边缘部分添加了交互功能。

异步组件：数据获取的革命

经典的 React 从不允许组件函数是异步的。无法在组件主体中直接使用 await —— 人们只能手动编写 useEffect 并处理加载状态。

服务端组件打破了这一限制：它们可以是 async 的。这看似只是语法上的微小补充，却极大地改变了底层架构。

// ✅ Server Component: Direct data access, no useEffect
async function BlogPostList() {
  // This runs on the server. No fetch call in the browser.
  const posts = await db.post.findMany({
    orderBy: { createdAt: 'desc' },
    take: 10
  });

  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.excerpt}</p>
        </li>
      ))}
    </ul>
  );
}

注意这里缺失的所有内容。没有用于跟踪加载状态的 useState，没有触发数据获取的 useEffect，也没有手动构建的骨架屏。该组件直接将数据库记录映射为 React 元素。现在数据获取是在每个组件内部进行，而非按路由处理，且完全在服务器端完成，绝不在浏览器中执行。

正因为如此，瀑布流问题便不复存在——服务器可以在向客户端发送响应之前同时处理所有异步组件。数据库调用在与后端相同的数据中心内执行，因此延迟以微秒计，而非通过移动网络连接时常见的毫秒级延迟。

“use client”指令：何时使用及原因

添加"use client"可将文件标记为属于浏览器运行时环境。每当组件需要操作本质上属于客户端的功能时，就需要使用它：

通过useState或useReducer管理本地状态
使用如useEffect或useLayoutEffect之类的生命周期钩子
处理事件，例如onClick或onSubmit

直接的浏览器 API — localStorage、window、document

与浏览器上下文相关的钩子，包括某些 useRouter 的用法以及 useMediaQuery 之类的功能

常见的错误是将该指令放在组件树的过上层。开发者常常仅仅因为某个嵌入的按钮需要交互功能，就将其整个页面转换为客户端组件。

// ❌ Bad: Making the whole page client-side for one interactive element
'use client';
import { useState } from 'react';
import { HeroSection } from './HeroSection'; // Static, could be server
import { LikeButton } from './LikeButton';   // Interactive, needs client
export default function Page() {
  return (
    <div>
      <HeroSection />
      <LikeButton />
    </div>
  );
}

在那个代码片段中，HeroSection纯粹是静态标记，本可以继续由服务器渲染。但由于在父级声明了 "use client"，其下的所有导入内容——包括那个静态部分——都会被打包并发送到浏览器中。

解决方案：将 "use client" 放在更下层的组件中

解决办法是将页面本身作为服务器组件，而将交互部分视为被导入到该组件的叶子节点。

// ✅ Good: Page is server, only LikeButton is client
// page.tsx (Server Component by default)
import { HeroSection } from './HeroSection';
import { LikeButton } from './LikeButton';
export default function Page() {
  return (
    <div>
      <HeroSection />
      <LikeButton postId="123" />
    </div>
  );
}

// LikeButton.tsx
'use client';
import { useState } from 'react';
export function LikeButton({ postId }) {
  const [liked, setLiked] = useState(false);

  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? '❤️' : '🤍'}
    </button>
  );
}

采用这种结构后，HeroSection和Page都不会以JavaScript的形式被发送到浏览器。只有LikeButton及其useState调用会被发送过去。这正是实现零包体大小目标的实用机制：尽可能将组件树的大部分留在服务器端，仅将真正需要交互功能的特定节点保留在客户端。

交错设计：让RSC如此强大的模式

RSC真正强大的技术在于交错嵌套——将服务器组件嵌入客户端组件中，通过属性传递来自服务器的数据，并让这些客户端组件提供可容纳更多服务器组件的children插槽。

// Layout.tsx (Server Component)
import { Sidebar } from './Sidebar';
import { AnalyticsProvider } from './AnalyticsProvider';
export default async function DashboardLayout({ children }) {
  // Fetch user data on the server
  const user = await getCurrentUser();
  const permissions = await getUserPermissions(user.id);

  return (
    <div className="dashboard">
      <Sidebar user={user} permissions={permissions} />

      {/* AnalyticsProvider is a Client Component */}
      <AnalyticsProvider userId={user.id}>
        {/* children here can be a Server Component page */}
        <main>{children}</main>
      </AnalyticsProvider>
    </div>
  );
}

// AnalyticsProvider.tsx
'use client';
import { createContext, useContext } from 'react';
const AnalyticsContext = createContext(null);
export function AnalyticsProvider({ userId, children }) {
  // Client-side analytics initialization
  useEffect(() => {
    analytics.identify(userId);
  }, [userId]);

  return (
    <AnalyticsContext.Provider value={{ userId }}>
      {children}
    </AnalyticsContext.Provider>
  );
}

此处，DashboardLayout在服务器端运行并直接查询数据库。它将获取的数据传递给Sidebar，而Sidebar根据需求可能本身是服务器组件或客户端组件。此外，该布局还会用AnalyticsProvider包裹页面的其余部分，这是浏览器中用于加载第三方分析库所必需的客户端组件。

关键在于 children 属性。无论在 AnalyticsProvider 内部渲染什么内容，仅仅因为它们嵌套在那里就未必必须变成客户端代码。React 会通过 children 将服务器组件已渲染的输出以流的形式传递给客户端组件——客户端组件仅起到包装或边界的作用，而非强制其中所有内容都在客户端运行的转换器。

混合式 UI 正是通过这种方式构建的：在真正需要交互性的地方，将服务器端渲染的内容嵌套在仅适用于客户端的包装组件中。

RSC 载荷：内部原理探析

服务器组件渲染并不会直接生成 HTML。相反，React 会输出 RSC 载荷，这是一种二进制流，其结构大致如下：

1:I["node_modules/react/jsx-runtime.js", "jsx"]
2:I["./components/ClientWidget.js", "default"]
0:["quot;, "div", null, {"children": [
  ["quot;, "h1", null, {"children": "Latest Posts"}],
  ["quot;, "@2", null, {"postId": "123", "title": "Hello World"}]
]}]

该流中的每一行都是一条指令。$符号表示一个React元素，I则表示导入了一个客户端组件模块。像@2这样的引用指向第二次导入的模块，在此例中即为ClientWidget。需要注意的是，服务器已经完全渲染了

标签，而对于`ClientWidget`，它仅传递了属性并指明了其代码所在的位置，并未自行进行渲染。

浏览器接收到该数据流后，会解析其中的导入引用，获取所需的客户端组件包，并构建最终的组件树。由于数据是分批传输的，浏览器无需等待全部数据到位即可开始渲染。正是这种渐进式传输方式，使得RSC能够在避免常见的水合瓶颈问题的同时支持流式服务器渲染。

缓存与重新验证

Next.js 15及更高版本让服务器组件能够使用各种缓存策略：

静态渲染（默认方式）。除非组件读取动态数据或执行未缓存的请求，否则它会在构建时被静态渲染。

// Cached indefinitely at build time
async function ProductList() {
  const products = await fetch('https://api.example.com/products');
  // ...
}

动态渲染。调用cookies()、headers()或读取searchParams，或是显式设置export const dynamic = 'force-dynamic'，都会迫使组件在每次接收到请求时都重新渲染。
定时重新验证。

// Revalidate every 60 seconds
async function ProductList() {
  const products = await fetch('https://api.example.com/products', {
    next: { revalidate: 60 }
  });
  // ...
}

按需触发重新验证。

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
export async function POST() {
  revalidatePath('/products');
  return Response.json({ revalidated: true });
}

关键在于，现在的缓存行为是针对单个组件而非整个路由来设定的。位于同一页面上的两个组件可以遵循完全不同的缓存规则。这种细致度在传统的SSR中是不存在的，因为在传统SSR中，一个缓存头部信息会同时控制整个页面。

长期存在的误解

“服务器组件主要存在是为了提升SEO效果。”其实并非如此——更好的搜索索引只是附带结果，而非最终目标。真正的目的是减少客户端JavaScript代码量，并让数据获取在组件层面完成。

“任何使用hook的组件都需要use client。”只有当该hook确实依赖浏览器API时才成立。React 19版本的use hook允许在服务器组件内部直接处理承诺对象并读取上下文，因此许多hook无需接触客户端就能正常工作。

“服务器组件会让API路由变得过时。”事实并非如此——两者可以协同使用。服务器组件负责在首次渲染时获取数据，但您仍然需要API路由来处理数据变更、来自第三方的webhook消息，以及水合之后在客户端进行的任何数据获取操作。

“服务器组件没有状态。”它们不具备浏览器式的状态——没有 useState 这样的功能——但可以自由访问数据库、缓存、文件系统以及环境变量等服务器端状态源。

“在服务器组件中不能使用 Context。”确实无法在服务器组件内部使用 React Context，因为 Context 的存在正是为了解决客户端渲染的组件树中 prop 传递层级过深的问题。此时可以改为通过普通 prop 来传递数据，由于服务器端渲染会从上到下同步解析组件树，Next.js 还提供了 unstable_rootParams 等选项，作为普通 prop 传递方式的补充。

2026 年前的发展现状

随着 React 19 已经稳定发布，相关的工具也有了显著进步：

Server Actions 允许客户端组件直接调用在服务器上运行的异步函数，从而在数据变更时弱化客户端与服务器之间的界限。
use 钩子为客户端组件提供了一种无需使用 useEffect 即可解包承诺值和上下文的方式。
Next.js 15 中的局部预渲染功能使得可以直接从 CDN 提供静态外壳，而动态内容则从源服务器流式加载。
React 编译器会自动处理客户端组件的记忆化，减少手动调用 useMemo 的需求，从而使客户端与服务器之间的切换更加流畅。

目前，这一概念模型已经稳定下来。服务器组件不再是可选择性启用的功能——它们才是构建现代 React 应用程序的基础前提。而客户端组件则成了例外：它是专为交互层设计的特殊解决方案。

不仅是性能的提升，更是架构的变革

React 服务器组件并非仅仅是性能上的优化手段，它代表着对 React 代码实际执行位置的重新思考。在大约十年的时间里，React 本质上仍是一个浏览器库，为了满足 SEO 需求才被改造为可在服务器端运行。如今它已截然不同：成为一个全栈组件系统，能够在网络连接的两端运行，且每一端都有明确的边界、职责和性能特征。

服务器已不再仅仅是获取数据的地方——它现在是一个真正的渲染环境。而浏览器也不再是React组件的唯一载体，交互功能恰恰存在于其中。

一旦理解了这个框架，关于RSC的许多困惑就会消失。问题从“这里需要使用use client吗？”转变为“这段特定的逻辑应该放在哪里？”。这才是值得思考的问题，也是随着应用发展所需具备的思维方式。