# 渲染光谱 · CSR / SSR / SSG / ISR 一图看清

> CSR、SSR、SSG、ISR 四个词，本质是同一个问题的不同答案——「什么时候、在哪里，把页面渲染出来」。这一章把它们摆进一张全景图，讲清各自的新鲜度、TTFB、扛量与场景，也为后面的缓存讨论立好坐标系。

- 作者：David（道雾轩）
- 专栏：SSR 从入门到精通（https://daiw.org/manual/ssr.md）
- 最后更新：2026-07-14
- 原文：https://daiw.org/manual/ssr/rendering-spectrum
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 渲染光谱 · CSR / SSR / SSG / ISR 一图看清

CSR、SSR、SSG、ISR——这四个缩写是 SSR 世界里最容易让人晕的地方。但只要抓住一个核心问题，它们立刻就理顺了：

> **页面到底是「什么时候」、在「哪里」被渲染出来的？**

「什么时候」有三个答案：**构建时**、**请求时**、**运行时（在客户端）**。四种策略，就是这几个答案的不同组合。

## 四种策略，各在光谱的一端

**CSR（客户端渲染）** —— **运行时，在用户的浏览器里**渲染。服务器只发空壳。→ 上一站讲过的[痛点](https://daiw.org/manual/ssr/csr-pain)全在这。

**SSR（服务端渲染）** —— **每次请求时，在服务器上**渲染。每个请求都现算一份 HTML。→ 首屏快、内容实时，但每请求都要渲染，[贵](https://daiw.org/manual/ssr/what-is-ssr)。

**SSG（静态站点生成，Static Site Generation）** —— **构建时，一次性**把所有页面渲染成静态 HTML 文件。之后所有用户拿到的是**同一份**预先生成好的 HTML，直接由 CDN 分发。→ 快到飞起、几乎零服务器成本，但内容**冻结在构建那一刻**，要更新就得重新构建。

**ISR（增量静态再生，Incremental Static Regeneration）** —— **SSG + 定期 / 按需再生**。先像 SSG 一样发预生成的静态页（快），但会在后台**按一定策略重新生成**（比如「最多 60 秒旧」），让静态页也能「渐渐更新」。→ 兼得 SSG 的速度和「内容不至于太旧」。这是 SSG 和 SSR 之间的**中间态**，后面[专门一章](https://daiw.org/manual/ssr/isr)细讲。

## 一张全景表

把它们并排比较，取舍就清楚了：

| 策略 | 何时渲染 | 每个用户看到的 | 新鲜度 | TTFB | 扛并发 | 典型场景 |
| --- | --- | --- | --- | --- | --- | --- |
| **CSR** | 客户端运行时 | 各自现画 | 实时 | 快（空壳） | 好（服务器轻） | 后台、仪表盘、内部工具 |
| **SSR** | 服务端每请求 | 服务器现画 | **实时** | **慢** | **差（须靠缓存）** | 个性化页、高频变动数据 |
| **SSG** | 构建时一次 | 同一份静态 | **构建那刻（旧）** | **极快** | **极好** | 博客、文档、营销页 |
| **ISR** | 构建 + 定期再生 | 同一份（定期换新） | 近实时 | 极快 | 极好 | 电商列表、新闻、榜单 |

盯着「新鲜度」和「扛并发」这两列看，你会发现一条**核心矛盾**：

<Callout type="warn">
  **越新鲜，越难扛量；越好扛，越不新鲜。**

  SSR 最新鲜（每请求现算），但正因为每请求现算，最难扛并发。SSG 最好扛（静态文件、CDN 分发），但内容最旧（冻在构建时）。这条矛盾，是整个渲染策略选择的主轴——而**缓存，正是用来在这条轴上「作弊」的**：它想让你既拿到接近 SSR 的新鲜度，又拿到接近 SSG 的扛量。这也是为什么本专栏把缓存当成重点。
</Callout>

## 关键：它们不是「四选一」

一个常见误解是「一个站点只能选一种」。其实现代框架里，**渲染策略是「每个页面（甚至每个组件）分别选」的**：

- 博客文章页 → SSG（内容不常变，构建时生成）。
- 商品列表页 → ISR（内容会变但能容忍几十秒延迟）。
- 用户个人中心 → SSR（强个性化，必须实时）。
- 后台仪表盘 → CSR（SEO 无关，交互极频繁）。

**同一个站点，不同页面用不同策略，是常态、也是最优解。** 「精通 SSR」很大程度上就是「精通为每个页面挑对策略」。

<Callout type="info">
  你可能还听过 **SSG + 客户端补充**（先发静态壳，再在客户端拉动态部分）、**PPR（Partial Prerendering，部分预渲染）** 等更细的组合。别被名词吓到——它们全都是在这张「构建时 / 请求时 / 运行时」的光谱上做**混搭**：哪部分能提前算就提前算（偏 SSG），哪部分必须实时就实时（偏 SSR）。抓住「何时渲染」这根轴，再花哨的组合都能看穿。
</Callout>

## 小结与下一章

CSR / SSR / SSG / ISR，本质是「何时、何地渲染」的不同答案，核心矛盾是**新鲜度 vs 扛量**，而缓存是用来突破这个矛盾的手段。它们不是四选一，而是**按页面混搭**。

渲染的地基打完了。第二站，我们看 SSR 这些年是怎么「变聪明」的——它没有停在「每请求傻傻地整页渲染」，而是学会了**边算边发**。下一章讲流式渲染：让浏览器不必等整页渲染完，而是**一块一块**地收到 HTML。👉 [流式渲染：别等全部，边算边发](https://daiw.org/manual/ssr/streaming)。

## 参考文献

- [1] web.dev.「Rendering on the Web.」https://web.dev/articles/rendering-on-the-web —— CSR/SSR/SSG 光谱与取舍。
- [2] Next.js 文档.「Rendering: Static / Dynamic / ISR / PPR.」https://nextjs.org/docs/app/building-your-application/rendering —— 各渲染策略与混搭。
- [3] Vercel.「A Complete Guide to Incremental Static Regeneration.」https://vercel.com/blog/incremental-static-regeneration —— ISR 的定位。