React 服务端直出与客户端请求边界
React SSR 场景下服务端直出与客户端请求的职责边界，以及它们和首屏体验、交互节奏之间的关系。
#tech / dev / frame
#resource / react
#type / synthesis
#status / growing
[!info] related notes
React 服务端直出与客户端请求边界
SSR 场景里最容易答散的问题，就是“哪些内容应该先由服务端直出，哪些内容可以留到客户端再请求”。
一句话定义
服务端直出更适合首屏必须稳定看到的内容；客户端请求更适合交互后才需要、个性化更强、或可以延后加载的内容。
为什么这组边界要单独理解
- 它决定用户第一次看到的页面是否完整
- 也决定页面接手后是不是还要立刻补很多请求
- 如果边界划错，可能同时损害首屏体验和交互节奏
服务端直出更适合什么
- 首屏主内容
- SEO 依赖的正文信息
- 页面结构强依赖的数据
客户端请求更适合什么
- 用户登录后才知道的个性化附加信息
- 点击、筛选、分页、展开后才需要的数据
- 可延迟展示、不影响首屏主体判断的内容
一个常见的平衡思路
- 先让用户看到稳定的页面骨架和核心内容
- 再让客户端按交互节奏补增量信息
- 不要为了“全服务端”把非关键内容全塞进首屏阻塞链路
常见误区
- 以为 SSR 页面就不该再有客户端请求
- 以为所有数据都客户端拉最灵活，所以首屏空一点没关系
- 只看技术路线，不看业务对首屏完整度的要求
最短记忆方式
先直出用户一进来必须看到的，再请求用户接下来才需要的。
面试要点
来自 react-server-render-vs-client-request-boundary-interview-question 的面试视角整理。
一句话回答
首屏必须稳定看到、影响页面主体判断和 SEO 的内容更适合服务端直出；交互后才需要、个性化更强或可以延后加载的内容更适合客户端再请求。核心是围绕首屏价值和交互节奏划分，不是追求纯服务端或纯客户端。
最稳的回答主线
- 先说首屏主内容优先直出
- 再说交互后增量内容可放客户端请求
- 再补一句：边界不是固定技术答案，而是业务优先级答案
- 最后强调：目标是同时平衡首屏完整度和接手后的灵活性
一个更完整的面试表达
可以这样答：
我一般会按“用户一进来必须马上看到什么”来划分。影响首屏主体理解、SEO、页面主内容判断的数据，更适合服务端直出；交互后才需要、个性化更强、或者可以延后加载的内容，更适合客户端再请求。
所以这不是纯服务端或纯客户端的技术站队问题，而是围绕首屏价值和交互节奏做边界划分。
一个典型划分方式
更适合服务端直出的：
- 商品详情主内容
- 文章正文
- SEO 关键内容
- 首屏列表主体
更适合客户端再请求的：
- 个性化推荐
- 下拉翻页后的增量数据
- 非首屏评论区
- 用户交互后才展开的细节内容
面试里容易加分的一句
真正成熟的 SSR 方案，通常不是“把所有内容都提前渲出来”，而是先把用户最在意的第一屏做稳，再把剩余内容按交互节奏渐进加载。
常见追问
- 个性化内容一定不能服务端直出吗
- 为什么有些 SSR 页面加载后还是会继续发很多请求
- 这和 hydration 成本有什么关系
最短记忆方式
先稳首屏，再补增量。