RSC(React Server Components)是整部”跨端与全栈”史的当代终点。过去前后端的边界是一次网络请求——显眼、可见、在 Network 面板里。RSC 把这条边界搬进了组件树:“这个组件在服务端跑、那个在客户端跑”成了组件级的决定,边界变成了组件树里一条看不见的线。前端不再”调用后端”,而是直接”写一段在服务端运行的 UI”。这是范式转变,也是复杂度被内化到极致的一刻。

  Server Component (默认)          Client Component ("use client")
  ────────────────────────        ──────────────────────────────
  在服务端运行 / 渲染               在浏览器运行
  可直接 await 数据库 / 文件         可用 useState / useEffect / 事件
  零客户端 JS(不进 bundle)        会被打包进 bundle, 有交互
         │                                  ▲
         └──── 在同一棵组件树里交织 ─────────┘

// 这是一个 Server Component —— 直接在组件里 await 数据库, 这段代码永不发往浏览器
async function ProductPage({ id }) {
  const product = await db.product.find(id);   // 后端代码, 写在"组件"里
  return (
    <article>
      <h1>{product.name}</h1>
      <AddToCart id={id} />   {/* 这是 Client Component, 有交互, 才进 bundle */}
    </article>
  );
}

取数不再是”组件挂载后发一个请求”(useEffect + fetch),而是组件本身就在服务端、可以直接 await 数据源。 数据获取被吸进了渲染本身。

1. SPA 的原罪还没根治:把渲染和取数全搬到客户端,带来巨大的 JS bundle、白屏、瀑布式请求(组件挂载→请求→再渲染子组件→再请求)。详见 React 的”四、副作用”。
2. 取数与组件割裂:数据”属于”哪个组件、在哪取、怎么传,一直是 React 的老大难。状态管理、数据请求库满天飞,本质都是在弥补”组件无法直接拿数据”这个缺口。
3. 全栈框架虽顺滑,边界仍在:API routes / tRPC 让前端能方便地调用后端,但你心里始终有一条”这是前端、那是后端、中间隔着一次网络请求”的线。每次取数仍是一次显式的跨边界往返。

全栈化一路把后端往前端项目里搬:Node → API routes → BFF → tRPC,每一步都让那条网络边界更顺滑。RSC 是这条路的尽头——不是让边界更好穿越,而是让边界从”系统之间”消失到”组件之间”。

过去三十年,前后端的分界线一直架在网络协议上:HTTP 请求/响应是那道清晰的关卡。无论 SSR、SSG、BFF、tRPC 怎么变,“客户端”和”服务端”始终是两个用网络隔开的世界。

RSC 第一次把这条线画进了组件树内部:

         <App>                    ← Server
           ├─ <Nav>               ← Server(直接读配置/DB)
           ├─ <ProductPage>       ← Server(await 数据库)
           │     └─ <AddToCart>   ← Client("use client", 有交互)
           └─ <Footer>            ← Server
  ─────────────────────────────────────────────────────
    边界不再是"一次网络请求", 而是组件树里 Server/Client 的交界线

同一棵组件树,横跨服务端和客户端,边界是树里一条根据 "use client" 划出的线。 你写组件时就在决定”这段在哪运行”。这是对”前端 = 浏览器里跑的东西”这个三十年定义的根本改写——组件成了横跨前后端的统一抽象单位。

1. 隐形边界 = 新心智负担:过去看 Network 面板就知道前后端在哪交接;现在边界藏在组件树里,一个不小心在 Server Component 里用了 useState、或在 Client Component 里 import 了数据库,就会炸。“这段到底在哪跑”成了每行代码都要在脑子里维护的状态。
2. 认知分裂(cognitive split):Server / Client 两种组件能力不同(能 await DB vs. 能用 Hooks)、序列化规则不同(props 必须可序列化才能跨边界传)、错误信息晦涩。这是 React 在 Hooks 之后又一次抬高了入门曲线。
3. “复杂度守恒”的又一次印证:RSC 没有消灭前后端的复杂度,只是把它从”两个系统、一次请求”压缩进了”一棵树、一条线”。复杂度变得更隐蔽,也因此更难教、更难调试。
4. 生态与心智的撕裂期:大量为 CSR 设计的库(“use client” 才能用)、对 RSC 的误用、框架(主要是 Next.js App Router)与 React 本体的耦合争议——生态还在剧烈适应。
5. 强绑定全栈与部署:RSC 默认你有一个能跑组件的服务端/边缘环境,把前端进一步绑死在全栈与特定部署形态上。

RSC 是 跨端与全栈演进史 母题——“前端用一套 JS/TS 技能栈吞噬相邻领域”——的逻辑终点。它把”前端 vs. 后端”这个三十年的二分法,从”网络两端的两个系统”压缩成了”同一棵组件树里的一条线”。如果它成功,“前端”和”后端”作为分立工种的意义将被根本改写;如果它失败,人们会记得这是前端扩张冲得最远的一次,并从中学到”复杂度无法被消灭,只能被转移”这一课。无论哪种结局,它都标记了前端领土扩张抵达的最远疆界。