# SSR 从入门到精通

> 从 CSR 的痛点出发，把服务端渲染的原理、流式、服务端组件、边缘渲染一路讲透，并用近一半篇幅深挖 SSR 的成败命门——缓存。一篇讲透一个概念，原理优先，主流框架的实现作对照。

- 作者：David（道雾轩）
- 最后更新：2026-08-03
- 原文：https://daiw.org/manual/ssr
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 序 · 渲染这件事，为什么在两端之间摇摆了十几年

前端渲染的历史，是一部「在客户端和服务端之间反复横跳」的历史。

最早，页面在**服务端**拼好 HTML 发给浏览器（PHP、JSP 时代）。后来 SPA 兴起，渲染整个搬到**客户端**——服务器只发一个空壳 `<div id="root">`，剩下全靠 JavaScript 在浏览器里现画(CSR)。可没过几年，大家又发现 CSR 有一堆绕不过的痛：首屏白屏、SEO 抓不到、低端机上卡。于是渲染**又被推回服务端**——这一次，叫 SSR（服务端渲染），但它带回了水合、同构、以及最棘手的**缓存**问题。

这个专栏，就是要把这段「回到服务端」的故事讲透：**SSR 到底解决了什么、又引入了什么新麻烦、以及怎么把这些麻烦一个个摆平。**

## 这个专栏怎么讲

<Callout type="info">
  **一篇讲透一个概念，原理优先。** SSR 的世界术语密集——CSR、SSR、SSG、ISR、hydration、streaming、RSC、edge……很容易被缩写淹没。本专栏的办法是：**一个概念一章，先讲清「它想解决什么问题」，再讲「它怎么做到」，最后讲「代价是什么」。** 不堆术语，不背 API。
</Callout>

讲法上**原理优先、框架作对照**：我们讲的是 SSR 的**通用原理**，但会不断用主流框架（Next.js、Nuxt、SvelteKit、Remix、Astro）的具体实现来印证——它们表面 API 各异，底下是同一套东西。你理解了原理，换任何框架都能秒懂。

## 重点在缓存

<Callout type="warn">
  **如果只能记住这个专栏的一句话，那就是：SSR 的成败，九成在缓存。**

  SSR 的本质是「每次请求都在服务器上现算一遍 HTML」——这很慢、很贵。一个没有缓存的 SSR 站点，流量一大就会被自己的渲染开销拖垮。**真正让 SSR 在生产环境可用的，不是渲染本身，而是它周围那一整套缓存机制。** 所以本专栏用了**近一半的篇幅**（整整八章）专门讲缓存：从 HTTP 的 `Cache-Control`，到 CDN 边缘缓存、`stale-while-revalidate`、增量静态再生(ISR)、框架的数据缓存、缓存失效，再到最难的「个性化内容怎么缓存」。这部分，才是从「会用 SSR」到「精通 SSR」的分水岭。
</Callout>

## 路线图

分四站走：

**第一站 · 渲染：从客户端到服务端** —— 先讲清 CSR 到底痛在哪、SSR 是什么、把死的 HTML 唤醒的「水合」是怎么回事，以及 CSR / SSR / SSG / ISR 这四个词的一张全景图。打好地基。

**第二站 · 更聪明地渲染** —— SSR 也在进化：流式渲染（边算边发，不必等全部）、服务端组件（RSC / 岛屿架构，只在服务端跑一部分）、边缘渲染（把服务器搬到离用户最近的地方）。这三招大幅缓解了 SSR 的性能短板。

**第三站 · 缓存（本专栏重点，八章）** —— 从 HTTP 缓存基石讲起，一路深入 CDN 边缘缓存、`stale-while-revalidate`、ISR、框架数据缓存、缓存失效策略，最后啃下「带 Cookie / 鉴权的个性化内容怎么缓存」这块硬骨头。

**第四站 · 上生产** —— 该量哪些指标（TTFB、FCP、LCP、缓存命中率）、怎么排查，以及一张「什么场景选什么渲染策略」的决策树 + 常见坑清单。

## 读之前，你最好有

- **写过前端**：知道 SPA、组件、`fetch` 大概是怎么回事。用 React / Vue / Svelte 任意一个都行。
- **一点 HTTP 常识**：请求 / 响应、状态码、响应头(header)是什么。缓存那部分会大量和 HTTP 头打交道，不熟也没关系，[HTTP 缓存那章](https://daiw.org/manual/ssr/http-caching) 会从零补。
- **不怕「取舍」二字**：SSR 的世界里几乎没有「银弹」，每个方案都是一组权衡。这个专栏会反复问「代价是什么」——这也是「精通」和「会用」的区别。

准备好了，我们从那个把前端逼回服务端的源头问题开始——**CSR 到底痛在哪**：[CSR 的痛点：为什么要把渲染搬回服务端](https://daiw.org/manual/ssr/csr-pain)。

## 本专栏篇目

- [SSR 从入门到精通](https://daiw.org/manual/ssr.md): 从 CSR 的痛点出发，把服务端渲染的原理、流式、服务端组件、边缘渲染一路讲透，并用近一半篇幅深挖 SSR 的成败命门——缓存。一篇讲透一个概念，原理优先，主流框架的实现作对照。

### 渲染 · 从客户端到服务端

- [CSR 的痛点 · 为什么要把渲染搬回服务端](https://daiw.org/manual/ssr/csr-pain.md): 纯客户端渲染(CSR)把「空壳 HTML + 一大包 JS」发给浏览器，首屏白屏、SEO 抓不到、请求瀑布、社交分享没预览——这四个痛点，正是把渲染推回服务端的原因。
- [SSR 是什么 · 一次请求的服务端旅程](https://daiw.org/manual/ssr/what-is-ssr.md): SSR 让服务器在收到请求时，就地把组件渲染成完整 HTML 再发给浏览器——首屏立刻可见、爬虫能读到内容。这一章走一遍这段服务端旅程，并点破它的代价：每次请求都要现算，很贵。
- [水合 · 把死的 HTML 救活](https://daiw.org/manual/ssr/hydration.md): 服务端发来的 HTML 看得见却点不动——它是「死」的。水合(hydration)让客户端 JS 接管这份 HTML，装上事件、恢复状态，把它唤醒成可交互应用。这一章讲透水合的原理、它的「恐怖谷」、以及最坑的水合失配。
- [渲染光谱 · CSR / SSR / SSG / ISR 一图看清](https://daiw.org/manual/ssr/rendering-spectrum.md): CSR、SSR、SSG、ISR 四个词，本质是同一个问题的不同答案——「什么时候、在哪里，把页面渲染出来」。这一章把它们摆进一张全景图，讲清各自的新鲜度、TTFB、扛量与场景，也为后面的缓存讨论立好坐标系。

### 更聪明地渲染

- [流式渲染 · 别等全部，边算边发](https://daiw.org/manual/ssr/streaming.md): 传统 SSR 必须等整页渲染完才能发出第一个字节——一个慢查询拖垮整页。流式渲染让服务器先发出外壳，再把慢的区块「边算边发」流式补上，TTFB 大降、首屏更快。这一章讲清它的原理与 Suspense。
- [服务端组件 · 只在服务端跑的那部分](https://daiw.org/manual/ssr/server-components.md): 水合要把所有组件在客户端重跑一遍、把所有组件 JS 都发过去——但页面上大半内容其实不需要交互。岛屿架构和 React 服务端组件(RSC)让这部分「只在服务端跑、根本不下发、根本不水合」，把 JS 和水合开销砍到最少。
- [边缘渲染 · 把服务端搬到离用户最近的地方](https://daiw.org/manual/ssr/edge-rendering.md): 传统 SSR 跑在一台（或一处）中心服务器上，离用户远、延迟高。边缘渲染把 SSR 搬到遍布全球的 CDN 边缘节点上运行，离用户只有几十毫秒。但边缘运行时受限、且「离用户近」往往意味着「离数据库远」——这是它最核心的取舍。

### 缓存 · 本专栏重点

- [为什么 SSR 必须缓存 · 渲染一次，服务千次](https://daiw.org/manual/ssr/why-cache.md): SSR 每个请求都要现算 HTML——这很贵。缓存的本质，是让「渲染一次的结果」被复用千次万次。这一章讲清缓存为何是 SSR 的命门、缓存的分层结构，以及那条贯穿始终的「新鲜度 vs 扛量」权衡。
- [HTTP 缓存基石 · Cache-Control 全家桶](https://daiw.org/manual/ssr/http-caching.md): 浏览器和 CDN 到底怎么缓存，全由服务器的一个响应头说了算——Cache-Control。这一章把 max-age、s-maxage、public/private、no-cache/no-store、以及 ETag 条件请求讲透，它们是后面一切缓存策略的字母表。
- [CDN / 边缘缓存 · SSR 的 HTML 怎么被缓存](https://daiw.org/manual/ssr/cdn-caching.md): CDN 缓存是保护 SSR 源站最关键的一层：第一个请求触发一次渲染，之后成千上万个请求全从边缘秒回，源站再也碰不到。这一章讲清缓存键、命中状态、源站屏蔽，以及最凶险的「缓存击穿」。
- [stale-while-revalidate · 又快，又不太旧](https://daiw.org/manual/ssr/swr.md): 缓存 TTL 有个两难：设短了新鲜但常回源（慢），设长了快但容易旧。stale-while-revalidate 打破它——过期后先把旧的秒回给用户，同时后台悄悄更新。用户永远不等，缓存自动保鲜。这是 ISR 背后的核心机制。
- [增量静态再生 · SSG 与 SSR 的中间态](https://daiw.org/manual/ssr/isr.md): ISR 把 stale-while-revalidate 从 CDN 层上升到框架层：页面像 SSG 一样预生成、由 CDN 秒回，又能按时间或按需在后台重新生成——不必重新构建整站。这一章讲清它的再生机制、按需失效和 fallback。
- [数据层缓存 · 缓存数据，而不是 HTML](https://daiw.org/manual/ssr/data-cache.md): 有些页面 HTML 因人而异、没法整页缓存，但它底层用的数据是共享且昂贵的。这时该缓存的是数据，不是 HTML。这一章讲清请求记忆、跨请求数据缓存、全路由缓存三层，以及「HTML 缓存 vs 数据缓存」的分工。
- [缓存失效 · TTL、按路径、按标签、按需](https://daiw.org/manual/ssr/cache-invalidation.md): 「计算机科学只有两件难事：缓存失效和命名。」数据变了、缓存却还旧着，怎么让它精准更新？这一章讲清基于时间(TTL)与按需（事件驱动）两大流派，以及按路径、按标签失效——尤其是标签如何破解「哪些页面依赖这份数据」的难题。
- [个性化与缓存 · 每人不同的页面怎么缓存](https://daiw.org/manual/ssr/personalization.md): 「你好，张三」这种每人不同的页面，天生和共享缓存(CDN)水火不容——缓存了发给别人就是灾难。可我们又想要 CDN 的速度。这一章给出破局的整套工具：拆分静态壳与动态洞、按人群分段、边缘个性化、部分预渲染。这是缓存的压轴。

### 上生产

- [量化与排查 · TTFB、LCP 与缓存命中率](https://daiw.org/manual/ssr/measuring.md): SSR 上了生产，该盯哪些指标、怎么排查慢？这一章讲清 TTFB、FCP、LCP、INP 各测什么，以及 SSR 独有的健康指标——缓存命中率；再给一套「页面慢，是服务端还是水合的锅」的排查流程。
- [收尾 · 决策树与常见坑](https://daiw.org/manual/ssr/recap.md): 用一张「什么页面选什么渲染 + 缓存策略」的决策树，和一份贯穿全专栏的「新手十大坑」清单，把 SSR 从入门到精通的全貌收拢。