先记住这个答案
SSR 适合希望首次响应就有重要正文、页面需要按请求生成内容或公开入口重视可发现性的场景。代价包括请求侧数据与渲染耗时、服务端资源和缓存管理、两端环境兼容，以及客户端仍可能承担的 hydration 工作。更新不频繁的公开内容可以优先评估静态生成和缓存；强交互后台也可按实际首屏要求选择客户端渲染。应逐页判断，而不是因为站点用了 React 就统一启用或关闭 SSR。
- 公开正文与首屏目标决定收益
- 动态请求成本和缓存隔离决定运行负担
- SSR 仍要控制客户端代码与接管成本
收益来自更合适的内容交付时机
公开文档、题目和商品介绍常希望首次访问就获得标题与正文。服务端或预渲染输出可以让这些内容较早可读，也方便不能完整执行脚本的程序理解；但这并不自动保证搜索排名或每项性能指标改善。
如果页面内容长期不变，构建时生成或通过明确缓存策略分发，可能比每次请求都重新渲染更合适。若必须展示与当前请求相关的信息，则要说明为何不能共享缓存，以及如何限制个性化部分的范围。
服务端数据链路可能成为首屏瓶颈
动态 SSR 把数据读取与部分计算放进请求处理，慢接口或串行依赖会推迟对应内容到达。应记录数据等待、渲染和缓存命中情况；流式输出能提前发送已就绪部分，但关键内容仍受自身依赖约束。
服务端还要承担并发和故障隔离成本。公共内容可以共享缓存，包含用户身份的数据则需要正确的缓存键与隔离策略，避免不同用户读取同一份个性化响应；这比单纯增加一台渲染服务器更值得先设计。
双环境约束与客户端工作都要纳入预算
组件在服务端执行时不能随意访问 window 等浏览器对象，两端首次输出也要保持一致。第三方库是否支持服务端运行、初始数据如何安全传递、错误状态码如何表达，都会增加集成与调试工作。
需要交互的部分仍可能发送客户端代码并 hydration，因此 SSR 不是零脚本方案。大型后台如果核心价值在登录后的持续操作，应测量首次加载和后续交互的真实瓶颈，也可以只让公共入口使用预渲染而保留内部界面的合适模式。
容易答错的地方
- 用 SEO 需求推导所有页面都必须动态 SSR
- 公开内容需要可读响应，并不必然要求每次请求重新计算。静态生成、缓存和混合渲染都可能满足目标，应按更新频率和个性化需求选择，避免为稳定内容承担不必要的请求侧成本。
- 把后端渲染快当作浏览器体验已经解决
- 客户端包下载、执行、接管和后续交互仍会影响体验。需要观察真实设备上的内容绘制与关键操作，不应只报告服务端函数耗时，更不能忽略大组件树或第三方脚本带来的主线程压力。
面试官还会怎么问？
登录后台就一定不适合 SSR 吗？
不是。后台也可能需要更好的首次展示、受控的初始数据或特定架构集成。只是公开索引通常不是主要收益，应根据实际用户网络、交互模式和服务端成本证明价值，不能仅凭登录与否一刀切。
流式 SSR 能解决所有慢接口问题吗？
不能。它可以让已就绪内容先到达，但慢接口负责的内容仍要等待，关键外壳若依赖慢数据也无法凭空生成。应调整依赖和边界，验证先展示的部分是否真正对用户有用。
怎样给团队提出可评审的选型结论？
选取代表性页面，列出首屏正文、数据时效、个性化和交互需求，再测量候选方案的响应、内容绘制和交互成本。同时说明缓存与故障处理方式，让结论对应具体页面而非抽象偏好。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。