React Server Components 是 React 的未来吗

React Server Components 真的是 React 的未来吗？还是 Next.js 想让你买更多 Vercel 套餐？ 老实说，RSC 这个东西我用过一段时间，体感是：它解决了一个真问题（首屏 JS 体积），但同时引入了一个新问题（mental model 复杂度）。Server Component 不能用 useState、不能用 onClick，要 client 渲染必须显式声明 'use client'——这套规则学习曲线不算陡，但踩坑时调试很烦。 补充一些背景：RSC 是 React 官方在 2020 年 12 月提出的（Dan Abramov 团队），跟 SSR 是不同的东西——SSR 输出的是 HTML，客户端 hydrate 后才有交互；RSC 输出的是组件树结构，客户端按需 hydrate 部分组件。RSC 的优势是「更小的 bundle、更快首屏、直接访问服务端资源」，代价是「组件边界必须显式声明，调试链路变长」。 它和 Next.js App Router 的关系是：Next.js 是目前对 RSC 支持最成熟的框架，但 RSC 本身不依赖 Next.js。React 团队明确说过 RSC 是 React 核心能力，理论上任何框架（Waku、RedwoodJS、甚至自己写一个）都能实现 RSC 协议。只是目前工程化最舒服的路径是 Next.js。 更让我警惕的是 Vercel 的商业模式：他们投了大量资源推广 RSC，而 RSC 的最佳部署体验只在 Vercel 自己平台上。虽然规范是开放的，但「开放的规范 + 唯一舒服的实现」是个老套路了。 2025-12 Next.js 16 发布，引入了需要显式开启的 Cache Components 和 Model Context Protocol（MCP）集成，进一步把开发者绑向 Vercel 平台。然后 2025 年底爆出了 CVE-2025-55182——一个影响 Next.js 14.3.0-canary.77 到 16.0.6 的严重安全漏洞，允许未授权攻击者通过 RSC payload 执行任意系统命令。这个 CVE 给所有「RSC = 默认安全」的宣传浇了一盆冷水：服务端组件执行用户输入是一个新的攻击面，应用层必须自己做严格过滤。 我的判断是：RSC 适合大型内容站（博客、电商、文档），不适合强交互应用（编辑器、看板、IM）。如果你站点 80% 是静态内容 + 偶尔交互，那 RSC 是真香；如果你站点 80% 是交互 + 偶尔静态，那引入 RSC 是给自己找麻烦。 不要因为「未来」两个字就上，得看你的场景当下需要什么。技术本身是真的好，但商业捆绑和安全风险是真的存在。你可以在不上 Vercel 的前提下用 RSC（用其他部署平台），但需要自己处理基础设施和额外的安全审查。这就是开源世界里永恒的权衡：规范开放、实现集中、风险自担。