深入理解 CSR / SSR / SSG / ISR：前端四种渲染模式的本质与选型
在前端工程化发展过程中，“页面是如何生成 HTML 的”逐渐成为一个绕不开的话题。
CSR、SSR、SSG、ISR 本质上并不是框架概念，而是渲染发生的时间与位置不同。
一、什么是“渲染模式”
所谓渲染模式，本质只有一个问题：
页面的 HTML 是在什么时候、由谁生成的？
| 模式 | HTML 生成位置 | 生成时机 |
|---|---|---|
| CSR | 浏览器 | 运行时 |
| SSR | 服务器 | 请求时 |
| SSG | 构建环境 | 构建时 |
| ISR | 构建环境 + 服务端运行时 | 构建时 + 请求后 |
二、CSR（Client Side Rendering）
2.1 基本概念
CSR（客户端渲染）指的是：
服务器返回一个空壳 HTML，页面内容由浏览器执行 JavaScript 动态生成
典型的 SPA（Single Page Application）即 CSR 架构。
2.2 渲染流程
1. 浏览器请求页面
2. 服务器返回基础 HTML（只有一个挂载点）
3. 浏览器下载 JS
4. 执行 JS
5. 框架生成 DOM
6. 页面可见
示例 HTML：
<body>
<div id="app"></div>
<script src="/main.js"></script>
</body>
2.3 优缺点分析
优点
- 前后端分离彻底
- 架构简单，开发体验好
- 首屏之后交互性能优秀
- 非常适合复杂交互应用
缺点
- 首屏白屏时间长
- 对 SEO 不友好
- 弱网环境体验差
2.4 适用场景
- 后台管理系统
- 内部系统
- 对 SEO 无要求的应用
- 高交互、长生命周期页面
三、SSR（Server Side Rendering）
3.1 基本概念
SSR（服务端渲染）指的是：
服务器在接收到请求后，执行前端框架代码，生成完整 HTML 再返回给浏览器
浏览器拿到的 HTML 已经包含完整内容。
3.2 渲染流程
1. 浏览器请求页面
2. 服务器执行 Vue/React
3. 生成完整 HTML
4. 返回 HTML
5. 浏览器直接渲染页面
6. 下载 JS
7. Hydration（事件绑定）
3.3 Hydration（水合）机制
Hydration 的本质是：
让客户端 JS 接管服务器生成的 DOM，而不是重新创建 DOM
主要工作包括：
- 事件绑定
- 状态同步
- 校验 DOM 一致性
如果两端生成的 DOM 不一致，就会出现常见的 Hydration mismatch 问题。
3.4 优缺点分析
优点
- 首屏速度快
- SEO 友好
- 更好的可访问性（a11y）
缺点
- 服务器压力大
- 架构复杂度高
- 调试成本高
- 需要处理 Node / 浏览器环境差异
3.5 常见问题
window/document在服务端不可用- 请求数据的重复获取
- 状态在服务端与客户端同步问题
- Hydration mismatch
3.6 适用场景
- 官网
- 内容型网站
- 对 SEO 有明确要求的页面
- 首屏性能敏感页面
四、SSG（Static Site Generation）
4.1 基本概念
SSG（静态站点生成）指的是：
在构建阶段直接生成 HTML 文件，运行时不再执行渲染逻辑
用户访问时，服务器只是返回一个静态文件。
4.2 构建与访问流程
构建阶段：
1. 执行前端代码
2. 请求数据
3. 生成 HTML 文件
运行阶段：
1. 用户访问
2. CDN / 静态服务器直接返回 HTML
4.3 优缺点分析
优点
- 极致的首屏性能
- SEO 效果最好
- 几乎没有服务器计算成本
- 非常适合 CDN
缺点
- 不适合高频变更数据
- 构建时间可能较长
- 动态性弱
4.4 SSG + CSR 的常见组合
实际中常见模式是：
首屏内容由 SSG 提供，页面加载后通过 CSR 请求实时数据
这也是 Nuxt / Next / Astro 中最常见的实践方式。
4.5 适用场景
- 博客
- 技术文档
- 产品官网
- 帮助中心
四、ISR（Incremental Static Regeneration）
ISR 不是一种全新的渲染模式，而是 SSG 的“延迟更新版”。
它解决的是 SSG 最大的痛点之一：
静态 HTML 一旦生成，就只能等下一次构建才能更新。
4.1 基本概念
ISR（增量静态再生成）指的是：
页面在构建阶段生成静态 HTML，但在运行时可以按需、按周期重新生成并缓存最新 HTML
核心思想一句话概括：
“HTML 不是一次性生成的，而是可以被后台悄悄刷新。”
4.2 ISR 的核心特征
| 特征 | 描述 |
|---|---|
| 初始访问 | 返回已生成的静态 HTML |
| 后续访问 | 继续返回旧 HTML |
| 触发条件 | 达到 revalidate 时间或手动触发 |
| 更新方式 | 后台重新生成 HTML |
| 用户感知 | 几乎无感 |
4.3 运行流程（以 Next.js / Nuxt 为例）
构建阶段：
1. 生成初始静态 HTML
2. 部署到 CDN / 服务器
运行阶段：
1. 用户访问页面
2. 返回缓存的 HTML
3. 如果超过 revalidate 时间
→ 后台重新生成 HTML
4. 新 HTML 覆盖旧缓存
注意关键点：
重新生成发生在“请求之后”，但不阻塞当前请求
4.4 和 SSG 的本质区别
| 对比项 | SSG | ISR |
|---|---|---|
| HTML 生成时机 | 构建时 | 构建时 + 运行时 |
| 是否支持更新 | 否 | 是 |
| 更新方式 | 全量重新构建 | 单页面增量更新 |
| 实时性 | 低 | 中 |
| 架构复杂度 | 低 | 中 |
可以理解为：
ISR = SSG + 有条件的后台再生成
4.5 ISR 解决了什么问题？
ISR 主要解决三类真实工程问题：
1. 内容更新不频繁，但也不是“永不变”
例如：
- 博客文章
- 产品介绍页
- 文档页面
- 营销落地页
SSG 太死，SSR 太重，ISR 刚好。
2. 构建时间失控的问题
当页面数量很大时：
- 纯 SSG → 构建时间爆炸
- ISR → “先生成重要页面，其余按需生成”
3. 性能 + 成本的平衡
- 首屏性能 ≈ SSG
- 服务器压力 ≪ SSR
- 内容新鲜度 > SSG
4.6 ISR 的局限性
ISR 不是银弹，也有明确边界：
不适合：
- 强实时数据（股价、聊天）
- 用户强个性化页面
- 高频写入场景
适合：
- 内容型页面
- 低频更新但需要“看起来很新”的内容
五、SSR / SSG / ISR 的关系梳理
可以用一句话来区分三者：
- SSR：每个请求都算一遍
- SSG：只在构建时算一遍
- ISR：构建时算一遍，之后“按需再算”
六、四种模式完整对比
| 维度 | CSR | SSR | SSG | ISR |
|---|---|---|---|---|
| HTML 生成时机 | 运行时 | 请求时 | 构建时 | 构建时 + 运行时 |
| 首屏性能 | 一般 | 较好 | 最佳 | 接近 SSG |
| SEO | 差 | 好 | 极好 | 极好 |
| 服务器压力 | 低 | 高 | 极低 | 低 |
| 构建成本 | 低 | 低 | 高（页面多时） | 中 |
| 内容实时性 | 强 | 强 | 弱 | 中 |
| 架构复杂度 | 低 | 高 | 中 | 中 |
七、工程实践中的升级版选型建议
是否需要 SEO？
├─ 否 → CSR
└─ 是
├─ 是否需要实时数据？
│ ├─ 是 → SSR
│ └─ 否
│ ├─ 是否内容基本稳定？
│ │ ├─ 是 → SSG
│ │ └─ 否 → ISR
八、SO
CSR、SSR、SSG、ISR 并不存在“谁更先进”的问题，它们只是针对不同目标的工程方案：
- 首页 / 落地页 → SSG / ISR
- 内容详情页 → ISR
- 搜索 / 个性化页 → SSR
- 后台系统 → CSR
不是“选一种模式”，而是“组合使用”。
CSR / SSR / SSG / ISR 的本质不是技术高低，
而是“HTML 生成成本、时机、频率”的不同取舍。
理解四者的本质，有助于在架构设计阶段做出更合理的技术决策。
Finally
如果 you 正在使用 Next / Nuxt / Astro，你会发现它们的真正价值在于：
不是提供某一种渲染模式，
而是让你可以在同一个项目中自由切换 CSR / SSR / SSG / ISR。
这是现代前端框架发展的核心方向，也是前端工程化发展到今天的一个重要标志。
浙公网安备 33010602011771号