SSR（服务端渲染）

CSR 的问题与 SSR 的价值

纯客户端渲染（CSR）的典型流程：浏览器收到一个几乎空的 HTML，下载 JS bundle，执行框架，发起数据请求，渲染页面。在慢网络或低端设备上，用户可能要等 3-5 秒才看到有意义的内容。更严重的是，搜索引擎爬虫（Googlebot 虽然能执行 JS，但有配额限制）可能拿到空页面，导致 SEO 极差。

SSR 让第一次请求就返回渲染好的 HTML，浏览器可以立刻展示内容，再「注水」（hydration）让页面变得可交互。这个注水过程本身也有成本，过重的 JS bundle 会导致「可见但不可用」的尴尬状态。[1]

SSR 的几种变体

现代框架把渲染模式细分为多种：

• SSG（静态站点生成）：构建时就生成好 HTML，CDN 直接分发，速度最快，但内容无法实时更新
• ISR（增量静态再生）：Next.js 特有，静态页面在后台按设定间隔重新生成，兼顾速度和新鲜度
• Streaming SSR：Node.js 流式传输 HTML，让浏览器边接收边渲染，配合 React Suspense 可优先发送关键内容

「要不要 SSR」需要权衡：它增加了服务器负担和代码复杂度（同构代码需在服务端和浏览器两个环境都能跑），对纯后台管理系统意义不大，但对内容型网站几乎是标配。