CSR、SSR 与 SSG
作为渲染模式对比入口，串起 CSR、SSR、SSG 三种方式的生成时机、性能权衡与选型直觉。
#tech / dev / frontend
#type / synthesis
#status / evergreen
#resource / client-side-rendering
#resource / server-side-rendering
#resource / static-site-generation
[!info] related notes
CSR、SSR 与 SSG
CSR、SSR、SSG 经常一起出现，因为它们都在回答同一个问题：页面首屏 HTML 到底是在什么时候、由谁生成出来的。
范围
这不是三篇定义页的重复集合，而是一篇对比入口。它关心的是：
- 页面内容何时生成
- 谁承担首屏直出的成本
- 数据新鲜度和部署复杂度怎么权衡
- 为什么现代框架常把三者混合使用，而不是全站只选一种
为什么要放在一起理解
把 CSR、SSR、SSG 放在一起理解，核心不是背名词，而是建立一个稳定判断：
- 首屏体验更受什么影响
- 页面内容是否需要按请求实时变化
- 服务端链路、构建链路、CDN 缓存该承担多大复杂度
- 页面到底更像“高交互应用”、还是“内容分发页面”
关系与依赖
- 客户端渲染（CSR）：浏览器先拿到页面壳和脚本，再在客户端生成主要内容
- 服务端渲染（SSR）：请求到来时由服务端先渲染出 HTML，再交给浏览器显示
- 静态站点生成（SSG）：构建阶段提前生成 HTML，访问时直接分发
- SSR 和 SSG 往往都会和 hydration 一起出现，因为首屏内容直出后，客户端还要接管交互
- 现代框架常按路由混用三者：后台路由偏 CSR，内容页偏 SSR 或 SSG，局部再按组件拆分交互边界
对比与选型
| 模式 | HTML 主要生成时机 | 首屏直出 | 数据新鲜度 | 成本重心 | 常见场景 |
|---|---|---|---|---|---|
| [[client-side-rendering | 客户端渲染（CSR）]] | 浏览器拿到 JS 后 | 较弱 | 由客户端请求决定，更新灵活 | 前端资源体积、主线程执行 |
| [[server-side-rendering | 服务端渲染（SSR）]] | 每次请求时 | 较强 | 可按请求拿到最新数据 | 服务端渲染链路、缓存策略 |
| [[static-site-generation | 静态站点生成（SSG）]] | 构建阶段 | 较强 | 取决于构建频率和发布策略 | 构建产物、发布与 CDN 分发 |
一个实用的选型直觉
- 高交互、登录后控制台、个性化很强的页面，通常先考虑 CSR
- 需要首屏直出、SEO，且内容会随请求变化的页面，更常考虑 SSR
- 内容相对稳定、适合 CDN 缓存的大量页面，更常考虑 SSG
- 真正落地时，优先按“页面类型”选型，而不是要求整站只能有一种模式
对比与易混淆点
SPA / MPA 和渲染模式不是同一层问题
- SPA / MPA 更关心导航和页面运行时怎么组织
- CSR / SSR / SSG 更关心首屏 HTML 是谁生成、何时生成
- 二者经常组合出现，但不能互相替代
SSR / SSG 不等于“不要前端 JavaScript”
- 首屏 HTML 提前准备好，不代表交互也已经接上
- 只要页面还要完整交互，通常仍要下载客户端脚本并经历 hydration
不要把 SSR 当成性能银弹
- SSR 更容易把“先看到内容”提前
- 但如果服务端慢、缓存策略差、客户端接管很重，用户体感依然可能不好
- 继续看：首次可见与可交互时间