NextJS中RSC与RCC打印children输出差异原因咨询

核心背景 #

你观察到的差异本质是RSC和RCC的执行环境、渲染模型完全不同，虽然最终DOM输出一致，但中间处理children的逻辑天差地别。

1. 服务端组件（RSC）的children处理逻辑 #

RSC运行在Node.js服务器端，核心目标是直接生成HTML或RSC序列化Payload：

• 当MainComponent作为RSC时，父组件传递的<SmallComponent />会被编译成一个React元素对象，其中type就是SmallComponent的函数本身——这是因为服务器此时还未执行SmallComponent（RSC采用按需递归渲染，只有当需要生成对应HTML时才会执行子组件）。
• 服务器会先处理MainComponent的逻辑，输出<div>的框架，之后才会处理children对应的SmallComponent：如果SmallComponent是RSC，就执行它生成HTML；如果是客户端组件，就生成客户端占位标记，留给浏览器后续hydrate。
• 所以你在RSC中console.log(children)看到的是未执行的组件函数引用，这是RSC延迟执行机制的正常表现。

2. 客户端组件（RCC）的children处理逻辑 #

RCC运行在浏览器的React客户端runtime中，核心是完成hydrate和交互逻辑：

• 服务器会先把整个组件树序列化成RSC Payload发送给客户端，客户端React在hydrateMainComponent时，会自动将传入的children用Fragment包裹——这是React客户端统一处理children的默认行为（无论传入单个还是多个子元素，都会用Fragment标准化结构，避免数组/单元素的逻辑分支）。
• 此时你看到的type: Symbol(react.fragment)就是这个包裹后的结构，内部的children数组才是<SmallComponent />渲染后的实际元素对象。

为什么最终渲染结果一致？ #

不管是RSC还是RCC路径，最终都会将SmallComponent渲染为<span>Lorem Ipsum</span>：

• RSC路径：服务器最终会执行RSC类型的SmallComponent生成HTML，或由客户端hydrate时执行客户端类型的SmallComponent。
• RCC路径：客户端直接执行SmallComponent并渲染到DOM。
  两者仅在中间处理阶段的children内存结构不同，最终的DOM输出完全一致。

内容的提问来源于stack exchange，提问作者Alejandro Bar