React Server Components 到底解决了什么问题

RSC 出来挺久了，身边还是经常有人问：它和 SSR 有什么区别？这篇文章用我自己的理解把它讲清楚。

从一个问题说起

假设一个列表页，需要拉数据、渲染、再把整页 HTML 发给浏览器。SSR 已经能做到这一点，那 RSC 存在的意义是什么？

答案是：SSR 解决的是"首屏怎么快"，RSC 解决的是"客户端要发多少 JavaScript"。

传统 SSR 页面水合之后，整棵组件树都要在客户端跑一遍，所有组件的代码都得打进 bundle。而 RSC 允许一部分组件只在服务端执行——它们永远不会被打包进客户端代码。

一个直观的例子

一个博客文章页里，渲染 Markdown 的逻辑很重（marked、highlight.js 都不小），但它不需要任何交互：

// 这个组件只在服务端运行，不会进入 client bundle
import { marked } from 'marked'

export async function Article({ slug }: { slug: string }) {
  const post = await db.article.findUnique({ where: { slug } })
  return <div dangerouslySetInnerHTML={{ __html: marked(post!.content) }} />
}

只有标了 'use client' 的组件（比如评论框、点赞按钮）才会作为 JavaScript 发给浏览器。

它改变了什么

写了一段时间之后，我最大的感受是心态变了：默认所有组件都是服务端组件，只在"必须交互"的地方引入客户端组件，bundle 的体积自然就下来了。

代价是心智模型要重建：服务端组件不能用 state、不能加事件监听，props 必须可序列化。一开始会频繁踩坑，习惯了之后反而觉得边界很清晰。