何时不宜采用服务端渲染（SSR）？

确实，Next.js把React服务端渲染（SSR）的实现门槛降得非常低，而且SSR带来的首屏性能提升和SEO优化优势也很诱人——听起来好像是个“通吃”的方案，但实际上SSR并不是银弹，有些场景下强行使用反而会增加开发成本、降低效率，甚至带来性能问题。

先快速回顾下SSR的核心价值，方便我们对比场景：

• 首屏加载更快：服务器直接返回渲染好的HTML，用户不用等客户端下载完JS再渲染，对低带宽/低性能设备用户更友好
• 更优的SEO：搜索引擎爬虫能直接抓取到完整的页面内容，适合需要被搜索引擎收录的公开应用

接下来聊聊哪些场景不适合用SSR：

• 纯内部后台/工具类应用：这类应用的用户都是已授权的内部员工，根本不需要被搜索引擎收录，SEO优势完全用不上。而且SSR需要额外的服务器资源处理渲染请求，还得维护服务器端的渲染逻辑，反而不如纯客户端渲染（CSR）简单直接，开发和部署成本更低。
• 交互极度复杂的单页应用：比如在线代码编辑器、实时协作设计工具这类产品，大部分内容和交互都是在客户端动态生成的，SSR渲染的首屏内容和用户实际操作后的页面差异极大。这时SSR的首屏优势微乎其微，反而要额外处理服务端与客户端的状态同步问题，增加开发复杂度和潜在bug。
• 流量极低的小型应用：如果你的应用只是个人用的小工具、小众博客，用户量极少，SSR带来的性能提升用户根本感知不到，但却要额外维护服务器渲染的配置、处理部署的复杂度，性价比极低。这种情况用静态生成（SSG）甚至纯CSR反而更省心。
• 服务器资源有限的场景：SSR每个请求都需要服务器执行React代码来渲染HTML，当流量突增时，服务器的CPU和内存占用会急剧上升，容易导致服务崩溃。如果你的团队没有足够的服务器资源或运维能力，硬上SSR反而会带来稳定性隐患。
• 内容高频动态更新且无需SEO的场景：比如实时数据监控仪表盘，内容每秒都在刷新，SSR渲染的页面刚到客户端就已经过时了，还不如直接用CSR从API拉取最新数据，既减少服务器负载，又能保证内容实时性。

总的来说，SSR是个非常实用的工具，但要结合应用的实际需求来选择。好在Next.js也提供了静态生成（SSG）、增量静态再生（ISR）等多种渲染方式，完全可以根据不同页面的需求灵活搭配，没必要一刀切全用SSR。

内容的提问来源于stack exchange，提问作者Roy Awill