CSR、SSR 与 SSG：从系统权衡出发选择前端渲染策略

很多团队讨论渲染方案时，习惯把它当成“框架偏好”。这其实不准确。渲染本质上是内容交付策略：HTML 在哪里生成、数据在什么时候完成解析、缓存放在哪一层、延迟成本由谁承担。

当你不再把 CSR、SSR、SSG 视为页面模板选项，而是把它们当成系统级架构决策时，很多争论会自然消失。

先用一句足够准确的话定义三者

• CSR：浏览器下载 JavaScript，拉取数据，并在客户端完成渲染。
• SSR：服务端按请求生成 HTML，浏览器接收后再完成 hydration。
• SSG：在构建期或再生成阶段提前产出 HTML，并以静态资源方式分发。

如果只停留在这三句话，仍然不够。真正影响用户体验的是完整链路：

CSR
浏览器 -> HTML 壳 -> JS Bundle -> API 请求 -> 渲染 -> 可交互
 
SSR
浏览器 -> 服务端带数据渲染 -> HTML -> Hydration -> 可交互
 
SSG
浏览器 -> CDN/静态 HTML -> 如有需要再 Hydration -> 可交互

同一个站点甚至同一个页面，也完全可以混合使用多种策略。比如静态外壳加局部客户端交互，或服务端首屏加延迟加载模块，往往比“全站只选一种”更专业。

CSR：当浏览器才是真正运行时，它往往是最佳方案

如果页面高度个性化、SEO 不重要、交互状态复杂，且产品更像一个持续运行的客户端应用，而不是一篇文档，那么 CSR 通常是合理默认值。

典型场景包括：

• 登录后的后台系统
• 内部运营平台
• 协同编辑或高频状态更新工具
• 富交互图表、拖拽、编辑器、离线能力较强的产品

CSR 的优势

CSR 把首屏之后的大量工作交给浏览器。一旦应用启动完成，后续路由切换可以非常流畅，因为运行时、状态和缓存已经留在客户端。

同时，服务端可以专注于提供 API，而不是为每个请求承担完整的视图拼装。

CSR 的代价

CSR 的问题不在“能不能做”，而在“成本由谁承担”。浏览器要负责：

• 下载 JavaScript
• 解析与编译脚本
• 执行启动逻辑
• 请求数据并管理状态

这意味着在中低端移动设备上，CSR 的实际体验经常比本地开发时看到的差很多。即使 TTFB 不高，LCP 和可交互时间仍然可能被 JavaScript 执行成本拖慢。

CSR 最常见的失败模式

最典型的反模式，是页面先给出一个空壳和 loading，再层层串行请求数据：

HTML 壳
  -> 应用 Bundle
    -> 用户信息 API
      -> 权限 API
        -> 页面数据 API
          -> 渲染

这不是“前端架构现代化”，而是把延迟逐级放大。

SSR：当请求上下文会改变文档本身时，SSR 才真正有价值