---
title: "React Server Components 的心智模型"
date: "2025-01-12"
summary: "服务端组件不是「服务端渲染的组件」，它是一次关于数据边界的重新划分。理解这条边界，比记住 API 更重要。"
tags: ["React", "Next.js", "性能"]
draft: false
---

第一次接触 Server Components，最容易带着旧框架的直觉去理解它：**「这不就是 SSR 吗？」**

不是。SSR 是把同一个组件在服务端渲染成 HTML，然后在客户端**再跑一遍**完成 hydration。Server Components 是另一回事——它**只在服务端运行**，代码永远不会发送到浏览器。

## 两种组件，一条边界

在 App Router 里，组件默认是服务端组件。只有当文件顶部写了 `"use client"`，它才会成为客户端组件。

这条边界的关键含义是：

| | Server Component | Client Component |
| --- | --- | --- |
| 运行位置 | 仅服务端 | 服务端（首屏）+ 浏览器 |
| 能否用 `useState` | 否 | 是 |
| 能否直接读数据库 | 是 | 否 |
| 代码是否进 bundle | 否 | 是 |

所以选择不是「哪个更好」，而是「这个组件需要什么」：

- 需要读取数据、访问文件系统、使用密钥 → **Server**
- 需要 `useState`、事件处理、浏览器 API → **Client**

> 默认留在服务端，只在真正需要交互时才越过边界。

## 边界是单向的

数据只能从服务端流向客户端，不能反向。服务端组件可以渲染客户端组件，但客户端组件不能 `import` 服务端组件。

```tsx
// ✅ 服务端组件渲染客户端组件，可以把数据作为 props 传下去
export default async function Page() {
  const posts = await getPosts();

  return (
    <main>
      <PostList posts={posts} />
      <ScrollProgress />  {/* 客户端组件 */}
    </main>
  );
}
```

反过来不行，因为客户端 bundle 里没有服务端组件的代码。

需要注意的是，**props 必须可序列化**。函数、类实例、Date 之外的复杂对象都传不过去。

```tsx
// ❌ 函数无法跨过边界
<ClientChart format={(v) => v.toFixed(2)} />

// ✅ 传数据，让客户端自己格式化
<ClientChart values={values} precision={2} />
```

## 把服务端代码物理隔离

一个常见的 bug 是：某个工具函数本来只在服务端用，结果被链式 `import` 进了客户端组件，**连同数据库凭据一起**打进了浏览器产物。

`server-only` 包能在构建阶段拦住这类事故：

```ts
import "server-only";

export function getPosts() {
  // 这里可以安全地读取内容目录或查询数据库
}
```

只要有任何客户端组件（直接或间接）导入这个模块，构建就会失败。这比靠代码评审去发现可靠得多。

## 交互要沉到叶子节点

既然客户端组件会进 bundle，就应该让**边界尽可能靠近叶子**。

```tsx
// ❌ 整个页面变成客户端组件，所有文章数据都要走 props 传
"use client";

export default function ArticlePage({ post }) {
  const [liked, setLiked] = useState(false);
  return (
    <article>
      <MDXContent source={post.content} />
      <LikeButton liked={liked} onClick={() => setLiked(!liked)} />
    </article>
  );
}
```

问题在于：MDX 渲染器、语法高亮、整个文章正文——全部被拖进了客户端 bundle，只为了一个点赞按钮。

正确的拆法是让正文留在服务端：

```tsx
// ✅ 页面是服务端组件，只有按钮是客户端组件
export default async function ArticlePage({ params }) {
  const post = await getPost(params.slug);

  return (
    <article>
      <MDXContent source={post.content} />
      <LikeButton />
    </article>
  );
}
```

`ArticlePage` 和 `MDXContent` 都不进 bundle，`LikeButton` 才是唯一需要下载的交互代码。**交互的粒度决定了 bundle 的大小。**

## 常见误区

**误区一：客户端组件只在浏览器运行。**
客户端组件同样会在服务端做一次预渲染，用来产出首屏 HTML。所以它里面不能直接访问 `window`——除非放进 `useEffect`。

**误区二：服务端组件能保留状态。**
服务端组件每次请求都会重新执行，没有状态、没有生命周期，也不能用 `useEffect`。

**误区三：加了 `"use client"` 就「更安全」。**
恰恰相反——它意味着代码会发送给用户。加上这个指令应该是**有意识的选择**，而不是遇到报错就顺手加的补丁。

## 一个判断口诀

拿不准组件该放哪边时，问三个问题：

1. 需要 `useState` / `useEffect` 吗？→ 需要就是客户端
2. 有事件处理（`onClick` 等）吗？→ 有就是客户端
3. 涉及密钥、数据库、文件系统吗？→ 涉及就必须是服务端

三个都不沾，就**留在服务端**。这通常是默认且正确的选择。

## 小结

Server Components 真正改变的不是渲染性能，而是**数据的归属**。它让「这份数据该在哪里被读取」重新成为一个需要思考的设计问题，而不是把所有逻辑都堆到客户端再想办法优化。

想清楚边界画在哪里，比记住哪个 API 可用更重要。