从 hype 到 reality
当 React Server Components 在 2023 年底正式面世时，整个前端社区为之沸腾。"零客户端 JS"、"自动代码分割"、"直接访问数据库"——每一个 promise 都像是在宣告前端开发的新纪元。
一年后的今天，我们站在更冷静的位置回望：RSC 的确带来了 paradigm shift，但它的代价远比最初呈现的要复杂。
性能的真实收益
在数据密集型页面中，RSC 的优势无可争议。以仪表盘类应用为例，服务端渲染可以将首屏数据加载时间减少 40-60%，同时将传输给客户端的 JavaScript 体积削减 30% 以上。
一家电商平台的实测数据显示，迁移至 RSC 后，商品详情页的 LCP 从 3.2s 降至 1.8s，改善幅度达到 44%。
但并非所有场景都适合。对于交互密集的页面（如在线文档编辑器、设计工具），RSC 带来的收益有限，反而增加了架构复杂度。
开发者体验的折中
RSC 最被低估的问题是"心智模型断裂"。开发者不再能简单地将组件视为"运行在浏览器中的 UI 片段"，而需要时刻思考：这段代码在哪里运行？哪些数据可以序列化？哪些不能？
"use client" 和 "use server" 的边界划分，成了团队日常讨论最多的话题之一。一位资深 React 工程师坦言："我们花了 3 个月才让团队真正理解 RSC 的运行模型。"
架构复杂度的隐形成本
引入 RSC 意味着你的应用不再是纯粹的 SPA，也不是传统的 SSR——它成了一种混合体。这种混合带来了 runtime 的复杂性：
- 服务端与客户端的状态同步需要更精细的控制
- 错误边界需要同时覆盖两个运行时
- 测试策略需要重新设计
- 部署架构也从"静态文件 + API"变成了"Node.js 服务 + 静态资源"
结语
RSC 不是银弹，但它确实解决了前端开发中一个长期存在的根本矛盾：如何在提供丰富交互体验的同时，保持页面加载的极致性能。关键在于——选择合适的场景，而不是为了新技术而新技术。