我对 React Server Components 的看法：方向对了，代价被低估了

聊聊 React Server Components。这个话题我被问过太多次，干脆写下来。

RSC 解决的是真问题#

先说立场：我认为 RSC 的方向是对的。

客户端 bundle 无限膨胀是前端这十年最大的债。一个内容型页面，用户要下载渲染逻辑、数据请求逻辑、甚至 Markdown 解析器，只为看一篇静态文章——这是荒谬的。RSC 把「只在服务端有意义的代码」留在服务端，是对这种荒谬的系统性纠正。

数据获取和组件的合并也是真提升。async 组件直接 await 数据，比 useEffect + loading state 的瀑布流干净太多。

但代价被严重低估了#

我倾向于认为，RSC 的推广宣传低估了三个代价：

1. 心智模型的撕裂#

「这个组件跑在哪」变成了每个 React 开发者时刻要回答的问题。server / client 边界处处存在：不能传函数、不能传类实例、use client 的传染性……这些规则单个都不难，叠在一起就是持续的认知税。

2. 生态的割裂#

大量成熟的库假设自己跑在客户端。RSC 时代它们要么重写、要么被隔离在 client 边界内。这个迁移的时间尺度是以年计的，期间所有人都要忍受「这个库能不能在 server component 里用」的反复确认。

3. 调试体验的倒退#

跨越网络边界的组件树，报错栈变得难以理解。序列化边界上的错误信息至今仍然对新手极不友好。

我的建议#

如果你在做内容型、电商型网站，RSC（配合成熟框架）值得上。如果你在做重交互的 dashboard 类应用，我不确定收益能覆盖迁移成本——传统 SPA + 代码分割可能仍是更务实的选择。

另外说一句：React Router 现在的 SSR + loader 模式，其实已经拿到了 RSC 的大部分收益（服务端取数、减少客户端瀑布流），而心智模型简单得多。这也是这个博客用它的原因。

技术选型永远是权衡。方向正确不等于此刻就该 all in。