SSR 从入门到精通
从 CSR 的痛点出发，把服务端渲染的原理、流式、服务端组件、边缘渲染一路讲透，并用近一半篇幅深挖 SSR 的成败命门——缓存。一篇讲透一个概念，原理优先，主流框架的实现作对照。
序 · 渲染这件事，为什么在两端之间摇摆了十几年
前端渲染的历史，是一部「在客户端和服务端之间反复横跳」的历史。
最早，页面在服务端拼好 HTML 发给浏览器（PHP、JSP 时代）。后来 SPA 兴起，渲染整个搬到客户端——服务器只发一个空壳 <div id="root">，剩下全靠 JavaScript 在浏览器里现画(CSR)。可没过几年，大家又发现 CSR 有一堆绕不过的痛：首屏白屏、SEO 抓不到、低端机上卡。于是渲染又被推回服务端——这一次，叫 SSR（服务端渲染），但它带回了水合、同构、以及最棘手的缓存问题。
这个专栏，就是要把这段「回到服务端」的故事讲透：SSR 到底解决了什么、又引入了什么新麻烦、以及怎么把这些麻烦一个个摆平。
这个专栏怎么讲
一篇讲透一个概念，原理优先。 SSR 的世界术语密集——CSR、SSR、SSG、ISR、hydration、streaming、RSC、edge……很容易被缩写淹没。本专栏的办法是：一个概念一章，先讲清「它想解决什么问题」，再讲「它怎么做到」，最后讲「代价是什么」。 不堆术语，不背 API。
讲法上原理优先、框架作对照：我们讲的是 SSR 的通用原理，但会不断用主流框架（Next.js、Nuxt、SvelteKit、Remix、Astro）的具体实现来印证——它们表面 API 各异，底下是同一套东西。你理解了原理，换任何框架都能秒懂。
重点在缓存
如果只能记住这个专栏的一句话，那就是：SSR 的成败，九成在缓存。
SSR 的本质是「每次请求都在服务器上现算一遍 HTML」——这很慢、很贵。一个没有缓存的 SSR 站点，流量一大就会被自己的渲染开销拖垮。真正让 SSR 在生产环境可用的，不是渲染本身，而是它周围那一整套缓存机制。 所以本专栏用了近一半的篇幅（整整八章）专门讲缓存：从 HTTP 的 Cache-Control，到 CDN 边缘缓存、stale-while-revalidate、增量静态再生(ISR)、框架的数据缓存、缓存失效，再到最难的「个性化内容怎么缓存」。这部分，才是从「会用 SSR」到「精通 SSR」的分水岭。
路线图
分四站走：
第一站 · 渲染：从客户端到服务端 —— 先讲清 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 缓存那章 会从零补。
- 不怕「取舍」二字：SSR 的世界里几乎没有「银弹」，每个方案都是一组权衡。这个专栏会反复问「代价是什么」——这也是「精通」和「会用」的区别。
准备好了，我们从那个把前端逼回服务端的源头问题开始——CSR 到底痛在哪：CSR 的痛点：为什么要把渲染搬回服务端。