React 18新增的RSC与NextJS中SSR的核心差异是什么？

1. 运行环境与生命周期 #

• SSR：组件本质是客户端组件，先在服务端渲染成HTML字符串发送给客户端，客户端再下载组件对应的JS并执行hydrate（激活），最终组件会在客户端运行，拥有完整的客户端生命周期（比如useState、useEffect）。
• RSC：组件完全在服务端运行，不会被打包发送到客户端，也不需要hydrate。客户端只会接收RSC渲染出的UI片段和数据，不会执行RSC的任何JS逻辑。

2. 客户端包体积优化 #

• SSR：虽然首屏HTML是服务端生成，但客户端仍需下载所有组件的JS代码来完成hydrate，包体积并没有本质减少，只是首屏加载更快。
• RSC：服务端专属的组件逻辑（如数据库查询、后端API调用、敏感数据处理）完全留在服务端，不会被打包到客户端JS中，能大幅降低客户端需要加载的代码量，提升页面加载速度。

3. 数据获取方式 #

• SSR：数据获取依赖Next.js的getServerSideProps（或App Router中的async Page组件），数据需要先获取后通过props传递给页面组件，无法在组件内部直接访问服务端资源。
• RSC：可以直接在组件内部编写数据获取逻辑（比如直接调用数据库、内部服务），无需通过props传递数据——因为组件本身就在服务端运行，能直接访问服务端环境，避免了数据传递的冗余。

4. 交互性与组件组合 #

• SSR：渲染后的组件本身就是客户端组件，hydrate后天然支持交互（如点击事件、状态更新），不需要额外标记。
• RSC：本身是无交互的静态/数据驱动UI，若需要交互能力，必须嵌套使用'use client'标记的客户端组件。RSC负责提供服务端数据渲染的内容，客户端组件处理用户交互逻辑，两者分工明确。

5. 更新与复用机制 #

• SSR：每次请求都会重新渲染整个页面的HTML，客户端接收到后需要全量hydrate，更新粒度是整个页面。
• RSC：支持增量更新和组件级复用。当页面局部内容需要更新时，只需从服务端获取对应的RSC片段，无需重新渲染整个页面，也不需要全量hydrate，更新效率更高。

内容的提问来源于stack exchange，提问作者Badal Saibo