React Server Components 的落地边界：不是所有页面都适合 RSC

Next.js App Router 推广 RSC 之后，很多团队问“要不要全量迁”。我的判断是：RSC 适合“读多写少、数据靠近服务端、交互局部化”的页面，不适合“强客户端状态、频繁交互、离线优先”的界面。

适合 RSC 的典型场景：内容页、商品详情、后台列表、SEO 敏感页面。数据在服务端取，直接渲染，减少客户端 JS 和请求瀑布。交互部分用 Client Component 局部包裹，比如加入购物车按钮、筛选器。这样首屏更快，JS 体积更小。

不适合硬套 RSC 的场景：复杂表单、富文本编辑器、实时协作、大量本地状态的管理后台。这些页面客户端交互密集，RSC 带来的收益有限，反而增加“服务端/客户端边界”的心智负担。把所有东西都标 "use client" 等于没迁移，还多了构建复杂度。

落地时要注意三个边界：第一，Server Component 不能使用浏览器 API 和客户端状态；第二，Client Component 的 props 必须可序列化，别把函数和类实例传过去；第三，数据请求尽量在服务端聚合，避免客户端多个 useEffect 瀑布。

一个务实策略是“新页面优先 RSC，老页面按收益迁移”。先拿内容型页面试点，度量 LCP、JS 体积和开发体验，再决定是否扩大。RSC 是架构选择，不是版本升级。用对场景是收益，用错场景是负债。