先记住这个答案
典型 CSR 首次请求先得到页面外壳与资源入口，浏览器加载并执行 JavaScript，再获取或使用数据生成业务 DOM。SSR 则在服务端把组件和初始数据渲染为 HTML，浏览器可以先解析显示正文，之后加载客户端代码并通过 hydration 接管需要交互的部分。SSR 把一部分首屏生成工作前移，但不等于没有客户端计算，也不保证所有性能指标都更快；实际链路还受数据耗时、缓存、流式边界和 JavaScript 体积影响。
- CSR 的业务 DOM 主要由浏览器生成
- SSR 先提供正文 HTML，再接管交互
- 首屏可见与 React 可交互要分别测量
CSR 将主要界面生成留给浏览器
以公开题目页为例，若初始响应只有根容器，浏览器需要先下载入口脚本，执行路由与组件，再取得题目数据并创建正文。脚本或数据请求出错时，用户可能只看到外壳，因此要检查加载状态与失败路径。
并不是所有 CSR 都必须串行经历脚本之后才发数据请求。预加载、内嵌初始数据和资源缓存可以缩短链路；描述流程时应以实际网络记录为准，避免把常见的请求瀑布误说成架构不可改变的限制。
SSR 提前生成正文，但仍有服务端等待
SSR 请求通常需要完成路由匹配、数据读取与服务端渲染，才将相应 HTML 发给浏览器。浏览器可以在客户端包尚未执行时显示收到的文本与图片，不过服务端数据慢也可能推迟首字节和正文到达。
流式渲染允许先发送已就绪的外壳或边界，再补充后续内容，具体收益取决于边界位置与数据就绪情况。它不是跳过数据依赖，页面最关键的正文如果仍在慢边界里，用户照样需要等待。
正文可见之后，还有交互和后续导航
HTML 能展示不代表 React 状态和事件处理器已经接管。hydration 需要客户端代码与一致的初始输入，仍消耗解析、执行和协调时间；原生链接或表单则可能在 React 接管前已有浏览器行为。
后续站内导航可以由客户端路由更新局部界面，不必每次重复首次 SSR 流程。构建时静态生成也能提前提供正文 HTML，所以讨论某页面方案时，要分别说明 HTML 生成时机、缓存方式和客户端交互范围。
容易答错的地方
- 把 SSR 说成浏览器不执行 React
- 需要客户端交互的部分通常仍要加载相关代码并建立运行时状态。SSR 改变初始内容的来源，不能自动消除 JavaScript 体积和 hydration 成本，优化时仍需关注发送了多少交互代码。
- 只用首字节判断首屏方案优劣
- 首字节可能更快但正文仍在等待脚本，也可能略晚却直接带来完整内容。应同时观察正文到达、主要内容绘制和交互响应，并记录后端数据与缓存命中情况，才能解释用户实际体验。
面试官还会怎么问？
静态生成属于哪一段流程的变化？
静态生成把 HTML 生成提前到构建或预生成阶段，请求时可直接分发已有内容。浏览器仍可能需要 hydration，因此它改变的是生成时机和服务端请求成本，并不等于完全没有客户端交互代码。
SSR 会自动减少接口请求数量吗？
不会自动保证。初始数据可以复用给客户端以避免重复读取，但如果客户端挂载后又无条件请求同一数据，仍会产生额外请求。需要明确数据快照传递、缓存和重新验证策略。
面试中怎样清楚地讲这条链路？
选定首次打开某个 URL，依次说明响应包含什么、数据在哪里取得、正文何时形成、React 何时接管。然后补上缓存或流式渲染的影响，比笼统说服务端快、客户端慢更准确。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。