原理#

服务器发一个几乎为空的 HTML（带一个挂载点和一大包 JS）。浏览器下载并执行 JS 后，框架才把组件树渲染进 DOM。

1
import { createRoot } from 'react-dom/client';
2
import App from './App';
3

4
createRoot(document.getElementById('root')).render(<App />);

这一步执行之前，页面是白的。

常见误区#

• “CSR 响应速度快”要分两层看：HTML 文件本身小、秒下，但真正的首屏内容要等 JS 下载 + 解析 + 执行，所以白屏反而长。准确说：部署简单、交互强，首屏与 SEO 吃亏。
• 白屏根因：关键渲染路径被 JS 阻塞。
• SEO：Google 能执行 JS 后抓取，但有延迟与配额；对其他引擎不友好。内容型站点不宜押宝 CSR 的 SEO。

适用#

重交互的 SPA（后台、仪表盘）、不需被收录的内部工具。

原理#

请求到服务器 → Node 跑框架的服务端渲染 API 把组件转成 HTML 流 → 流式返回 → 浏览器先看内容，再由同款 JS 水合成可交互。

1
import { renderToPipeableStream } from 'react-dom/server';
2
import App from './App';
3

4
const stream = renderToPipeableStream(<App />, {
5
  bootstrapScripts: ['/client.js'],
6
});

要点与坑#

• SSR 返回的 HTML 只是“先有内容”，交互仍需客户端 JS 水合，否则按钮点了没反应。
• 服务器压力可缓解：把渲染结果缓存到 CDN / 边缘节点，命中缓存时和 SSG 一样快。
• 服务端代码不能访问 window / document / localStorage，这类逻辑必须放进 useEffect 或动态导入，否则在 Node 端拿到 undefined 甚至崩。
• 高频坑：水合不匹配（hydration mismatch）——服务端和客户端首屏渲染不一致（时间、随机数），React 会报警并可能整段重渲染。

适用#

首屏内容重要 + 需要个性化/实时数据（电商详情、社交动态、登录态页）。

原理#

构建期把“模板 + 数据”渲染成静态 HTML，部署后 CDN 直接返回。请求时无服务端计算，最快、最安全。

1
export async function getStaticPaths() {
2
  const posts = await getCollection('posts');
3
  return posts.map((p) => ({ params: { slug: p.slug } }));
4
}
5
const { slug } = Astro.params;
6
const post = await getCollection('posts', (p) => p.slug === slug);

1
<article>{post.data.title}</article>

常见误解#

• “每次更新都要重建并部署整站”过时了。现代 SSG（Astro / Hugo）有增量构建与缓存，只重渲变化页；配合 CDN 失效，更新成本远低于“重建整站”。
• “动态性受限”不绝对。SSG 页面默认静态 HTML，但可叠加客户端 JS 或群岛架构，需要交互的局部才 hydrate。

适用#

内容更新不频繁、对性能/安全/SEO 敏感的站点：博客、文档、营销页、官网。

1. 群岛架构 / 部分水合（Astro）#

SSG 页面默认 0KB JS，只有标了 client:* 的组件才作为“岛”单独 hydrate，互相独立：

1
<Counter client:visible />

把“SSG 的速度”和“组件化交互”统一了，内容站天然适合。

2. ISR（增量静态再生成）#

SSG + 定时/按需重渲染：页面先以静态形式服务，后台按间隔（或请求触发）重新生成，化解“频繁更新不适合 SSG”的顾虑。

3. Hybrid（Next / Nuxt）#

同一框架内按页面选 SSR / SSG / CSR。营销页走 SSG，用户页走 SSR，后台走 CSR。

总表#