React SSR 架构边界
React SSR 中服务端组件、客户端组件、服务端数据准备与客户端补请求之间的整体职责边界。
#tech / dev / frame
#resource / react
#type / synthesis
#status / growing
[!info] related notes
React SSR 架构边界
React SSR 真正难的地方，往往不是单独理解某个名词，而是把服务端组件、客户端组件、首屏数据和客户端增量请求放到同一条链里看清楚。
一句话定义
React SSR 架构边界的核心是：把首屏必须稳定输出的内容、可留在服务端的数据准备，以及真正依赖浏览器交互的逻辑拆到不同层次，各自承担最合适的职责。
为什么这页要单独存在
- 单看服务端组件，容易忽略数据阶段
- 单看数据获取，容易忽略交互归属
- 单看 hydration，又容易忽略哪些东西本来就不该进客户端
一条整体主线
服务端组件
- 更适合组织首屏内容和可在服务端完成的数据准备
- 目标是减少不必要的客户端逻辑进入接管链路
客户端组件
- 更适合承接事件、状态、effect 和浏览器能力
- 目标是只把真正需要交互的部分留给客户端执行
服务端阶段的数据
- 更适合首屏必须稳定展示的关键数据
- 目标是让用户第一次看到的页面更完整
客户端补请求
- 更适合交互后才需要或可以延后加载的增量信息
- 目标是让首屏链路不过度膨胀
应该怎么理解它们之间的关系
- 不是“服务端做得越多越高级”
- 也不是“客户端越灵活越通用”
- 真正重要的是：首屏内容、交互逻辑和后续增量更新要分层合理
常见误区
- 把 SSR 理解成“客户端请求会消失”
- 把服务端组件理解成“任何东西都该先放服务端”
- 把首屏完整度和后续交互节奏混成一个问题
最短记忆方式
服务端先把第一屏做稳，客户端接住交互，再按节奏补增量。
面试要点
来自 react-ssr-architecture-boundaries-interview-question 的面试视角整理。
一句话回答
首屏必须稳定展示的内容和关键数据，优先在服务端层完成组织与准备；真正依赖浏览器交互的状态、事件和 effect 留给客户端组件；首屏之后才需要的增量信息，再交给客户端按交互节奏请求。核心不是把一切都塞给某一端，而是让每一层只负责最适合自己的那部分。
最稳的回答主线
- 第一层先说首屏：服务端先把核心内容做稳
- 第二层再说交互：客户端组件负责浏览器侧能力
- 第三层再说数据：关键首屏数据提前准备，增量数据后置补拉
- 最后补一句：目标是平衡首屏完整度、接管成本和交互灵活性
一个更完整的面试表达
可以这样答：
我会把 SSR 架构拆成三层来看。
第一层是首屏内容和关键数据，优先在服务端完成，这样用户一进来就能看到完整主体；
第二层是浏览器交互能力，比如点击、输入、effect、客户端状态，这部分交给客户端组件；
第三层是首屏之后的增量数据，按交互节奏在客户端继续请求。
这样分工的目标不是偏向哪一端，而是平衡首屏质量、客户端接管成本和后续交互灵活性。
一个常见误区
不是说“能服务端做的就全部服务端做完”。
如果首屏做得过重，也可能：
- 拉长响应时间
- 提高服务端压力
- 让整页耦合过深
所以成熟方案强调的是合理分层，不是单端极端化。
面试里容易加分的一句
成熟的 SSR 架构不是“把所有东西都提前做完”，而是让首屏、交互和增量更新各自待在最合适的层次里，减少互相拖累。
常见追问
- 为什么 SSR 页面还会继续发很多请求
- 服务端组件和传统 SSR 到底差在哪
- 首屏做太重会不会反过来拖慢响应
最短记忆方式
第一屏服务端先稳住，交互客户端来接，增量数据按节奏补。