React SSR 数据获取位置
React SSR 场景下数据应该在什么阶段准备，以及它和 useEffect、首屏直出、客户端接管之间的关系。
[!info] related notes
React SSR 数据获取位置
SSR 讨论里，一个非常高频的问题不是“能不能请求数据”，而是“这份数据到底应该在哪个阶段准备”。
一句话定义
如果一份数据决定了服务端首屏直出的内容，它就应该尽量在服务端渲染阶段准备；如果一份数据只影响客户端交互或首屏之后的补充内容，再考虑放到客户端请求链路里。
为什么这个问题重要
- 数据放在哪，直接影响首屏是否完整
- 也会影响首次可见时间和可交互时间的平衡
- 还会影响客户端需要额外承担多少请求和接管成本
一条最实用的判断线
服务端阶段更适合的数据
- 首屏就必须显示的核心内容
- SEO 或分享首屏需要看到的内容
- 页面结构依赖它才能稳定输出的关键数据
客户端阶段更适合的数据
- 用户点击后才需要的增量数据
- 明显依赖浏览器环境或用户当前操作的数据
- 首屏之后再补齐也能接受的非关键内容
为什么不能把首屏数据都交给 useEffect
useEffect不在服务端执行- 如果首屏关键数据靠 effect 获取，首屏直出就会变空壳或不完整
- 用户可能先看到骨架，再等待客户端补数据
常见误区
- 以为用了 SSR，所有数据都应该只在客户端拉
- 以为所有数据都必须服务端取完才合理
- 不区分首屏关键内容和交互后增量内容
最短记忆方式
决定首屏长什么样的数据尽量提前在服务端准备，交互后才需要的数据再交给客户端。
面试要点
来自 react-ssr-data-fetching-interview-question 的面试视角整理。
一句话回答
决定首屏直出内容的关键数据通常应该在服务端阶段准备；只影响交互后体验或首屏后补充内容的数据，可以放到客户端请求链路。核心不是站队服务端或客户端，而是看这份数据对首屏的重要程度。
最稳的回答主线
- 先分首屏关键数据和非关键增量数据
- 首屏关键数据尽量提前准备，避免直出空壳
- 非关键数据可以在客户端补拉，减少服务端压力和首屏耦合
- 最后补一句：
useEffect不参与服务端首屏数据准备
一个更完整的面试表达
可以这样答：
SSR 场景里我一般先区分“首屏关键数据”和“首屏后增量数据”。真正决定首屏内容是否完整的数据，应该在服务端阶段准备好，这样 HTML 才不是空壳。
交互后才需要、对首屏不敏感的数据，可以放到客户端请求链路。
一个很关键的点是，useEffect不会参与服务端首屏 HTML 生成，所以不能指望它去准备首屏关键数据。
一个最常见的误区
很多人会说：
“我在页面里
useEffect(fetchData)就行了。”
这在纯 CSR 场景没问题，但在 SSR 里，如果首屏要直接看到数据，靠 effect 已经太晚了。
一个更工程化的结论
SSR 不是把所有请求都移到服务端，而是把“决定首屏质量”的那部分请求优先前置。
面试里容易加分的一句
SSR 不等于所有请求都放服务端，而是先把真正决定首屏体验的那部分数据准备好，剩下的再按交互节奏分给客户端。
常见追问
- 为什么不能把首屏数据全放进
useEffect - 什么数据更适合客户端再拉
- 服务端准备更多数据会不会拖慢响应
最短记忆方式
先保首屏关键内容，剩下的再按交互节奏补。