1. 先建立整体感觉#

如果你现在只想快速抓住区别，可以先看这张 Mermaid 图：

flowchart LR
  userVisit["用户访问页面"] --> prepareTime{"内容什么时候准备好?"}
  prepareTime --> buildTime["构建时\nSSG"]
  prepareTime --> requestTime["请求到来时\nSSR"]
  prepareTime --> browserTime["浏览器运行后\nCSR"]

  buildTime --> isrPath["可进一步做 ISR"]
  requestTime --> streamingPath["可配合 Streaming"]
  buildTime --> pprPath["可配合 PPR"]
  requestTime --> pprPath

它表达的是一个非常朴素的事实：

• 如果内容在 build 阶段准备好，那它更偏 SSG
• 如果内容在请求到来时准备好，那它更偏 SSR
• 如果内容是在浏览器里准备好，那它更偏 CSR

2. 先给结论：它们讨论的不是一件事#

最核心的一点是：

• SSR / CSR / SSG / ISR / PPR 更偏页面生成或内容输出策略
• Server Components / Client Components 更偏组件运行位置与交互边界
• Streaming 更偏响应传输方式

也就是说，它们不是完全同一维度的概念。

如果只用一句话来概括：

• SSR：请求来了再生成 HTML
• CSR：先给壳，浏览器再拿数据和渲染
• SSG：构建时提前生成 HTML
• ISR：先静态生成，之后按规则增量更新
• Streaming：边准备内容边把内容流式返回
• PPR：静态外壳 + 动态区域的混合输出策略

IMPORTANT

这些概念在现代 Next.js 项目里经常不是单选题。一个页面完全可能同时包含：SSG 的正文、CSR 的交互组件、SSR 的动态区域，以及 Streaming 的输出方式。

3. SSR、CSR、SSG 分别是什么#

sequenceDiagram
  participant U as 用户
  participant N as Next.js 服务端
  participant API as 数据源

  U->>N: 请求页面
  N->>API: 获取实时数据
  API-->>N: 返回数据
  N-->>U: 生成 HTML 并返回

export default async function Page() {
  const res = await fetch("https://api.example.com/orders", {
    cache: "no-store",
  });
  const orders = await res.json();

  return (
    <main>
      <h1>Orders</h1>
      <p>当前订单数：{orders.length}</p>
    </main>
  );
}

sequenceDiagram
  participant U as 用户
  participant H as 初始HTML
  participant B as 浏览器JS
  participant API as 数据源

  U->>H: 打开页面
  H-->>U: 返回页面壳
  U->>B: 浏览器执行脚本
  B->>API: 请求数据
  API-->>B: 返回数据
  B-->>U: 更新页面内容

"use client";

import { useEffect, useState } from "react";

export default function Page() {
  const [stats, setStats] = useState<{ count: number } | null>(null);

  useEffect(() => {
    fetch("/api/stats")
      .then((res) => res.json())
      .then(setStats);
  }, []);

  if (!stats) {
    return <div>Loading...</div>;
  }

  return <div>Count: {stats.count}</div>;
}

sequenceDiagram
  participant B as Build
  participant N as Next.js
  participant U as 用户

  B->>N: 执行 next build
  N-->>B: 预先生成 HTML
  U->>N: 请求页面
  N-->>U: 直接返回现成 HTML

export async function generateStaticParams() {
  return [
    { slug: ["components", "button"] },
    { slug: ["components", "card"] },
  ];
}

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string[] }>;
}) {
  const { slug } = await params;

  return <div>当前页面：{slug.join("/")}</div>;
}

4. 为什么在 App Router 里这些概念更容易混#

在 Next.js App Router 中，页面通常不是“纯 SSR”或“纯 CSR”那么简单。

一个页面很可能同时包含：

• 静态生成的正文
• 浏览器端的交互组件
• 服务端实时请求的数据块

例如一个文档页完全可能是：

• 文档正文：SSG
• 搜索框和主题切换：CSR
• 某个动态统计角标：SSR

这就是为什么在 App Router 里，「页面级策略」和「组件级边界」必须分开看。

flowchart TD
  page["一个页面"] --> staticBody["静态正文\nSSG"]
  page --> interactiveArea["交互按钮/主题切换\nClient Components"]
  page --> realtimeBadge["实时数据角标\nSSR"]
  page --> streamingArea["慢内容渐进返回\nStreaming"]

5. Server Components 和 Client Components 不是 SSR/CSR 的同义词#

CAUTION

本节是全文最容易误解的地方之一：不要把 Server/Client Components 直接等同于整页 SSR/CSR。

// app/docs/page.tsx
import { ThemeToggle } from "./theme-toggle";

export default async function Page() {
  const docs = await getDocs();

  return (
    <main>
      <h1>{docs.title}</h1>
      <ThemeToggle />
    </main>
  );
}

// app/docs/theme-toggle.tsx
"use client";

import { useState } from "react";

export function ThemeToggle() {
  const [theme, setTheme] = useState("light");

  return <button onClick={() => setTheme("dark")}>{theme}</button>;
}

6. ISR：它到底算不算 SSG#

ISR 全称是 Incremental Static Regeneration。

它可以理解为：

SSG 的增强版。

它的思路是：

1. 页面先静态生成
2. 之后在一定条件下重新生成
3. 不必每次都整站重新 build

所以 ISR 既保留了静态页面的高性能，也解决了纯 SSG 更新不够灵活的问题。

适合场景：

• 商品详情页
• 新闻列表页
• 内容更新频率中等的页面

它不等于 SSR，因为它不是每次请求都实时重新渲染；
它也不等于传统纯 SSG，因为它允许后续增量更新。

export const revalidate = 60;

export default async function Page() {
  const res = await fetch("https://api.example.com/posts");
  const posts = await res.json();

  return (
    <main>
      <h1>Blog</h1>
      <ul>
        {posts.map((post: { id: string; title: string }) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </main>
  );
}

7. Streaming：它不是新的“渲染种类”，而是传输方式#

Streaming 很容易被误以为是第四种渲染方式，其实更准确地说，它是：

把页面内容分块流式发送给浏览器的响应机制。

它适合解决的问题是：

• 页面某些部分很快能出来
• 另一些部分比较慢
• 不希望用户一直等整页完成

因此你可以理解为：

• 页面某部分先返回
• 慢的部分稍后继续流给浏览器

所以 Streaming 更像一种“输出方式”，而不是对 SSG/SSR/CSR 的替代。

import { Suspense } from "react";

export default function Page() {
  return (
    <main>
      <h1>Dashboard</h1>
      <Suspense fallback={<div>Loading chart...</div>}>
        <SlowChart />
      </Suspense>
    </main>
  );
}

async function SlowChart() {
  const res = await fetch("https://api.example.com/chart", {
    cache: "no-store",
  });
  const chart = await res.json();

  return <pre>{JSON.stringify(chart, null, 2)}</pre>;
}

8. PPR：为什么它最近常被拿出来单独讲#

PPR，即 Partial Prerendering，可以理解成：

静态外壳 + 动态内容洞位。

它试图结合静态预渲染和动态渲染的优点：

• 能提前输出稳定的页面结构
• 又能为某些动态区域保留实时能力

所以它不是在否定 SSG 或 SSR，而是在做更细粒度的组合。

更直观地说：

• Header、导航、主体外壳可以提前静态输出
• 个别慢数据、个别个性化区域再动态填充

这是一种更接近实际产品需求的混合模式。

flowchart TD
  page["页面"] --> staticShell["静态壳子\nHeader / Nav / 主体结构"]
  page --> dynamicSlots["动态洞位\n个性化信息 / 慢数据"]
  staticShell --> firstPaint["先返回给用户"]
  dynamicSlots --> fillLater["随后补齐"]

9. 在 Next.js App Router 里，应该怎么理解“静态”和“动态”#

如果你只记一个实用判断标准，可以记这个：

10. 一个文档页的典型拆解#

拿文档站来举例，最常见的组合其实是：

• 页面主体：SSG
• TOC、主题切换、搜索弹层：Client Components
• 某些辅助信息：按需动态获取

这也是为什么在现代 Next.js 项目里，“单选题思维”往往不够用了。
很多页面不是简单地“选 SSR 还是 CSR”，而是组合使用。

flowchart TD
  docsPage["/docs/components/button"] --> bodyArea["正文和目录结构\nSSG"]
  docsPage --> uiLayer["主题切换 / 搜索弹层\nClient Components"]
  docsPage --> dynamicMeta["更新记录 / Git 信息\n可按需动态获取"]

11. 最容易犯的几个错误#

CAUTION

错误 1：把 Server Component 理解成 SSR
不对。Server Component 只表示组件在服务端执行；页面仍可在 build 阶段被静态生成。

CAUTION

错误 2：把 Client Component 理解成整页 CSR
不对。SSG 页面里完全可以嵌套 Client Component。

CAUTION

错误 3：认为 SSG 就一定不能更新
不对。配合 ISR 后，静态页面可以增量再生成。

CAUTION

错误 4：把 Streaming 当成新的「渲染模式」
更准确地说，它是响应输出机制，不是对 SSR/SSG/CSR 的简单替代。

12. 实战选型建议#

TIP

文档站 / 博客 / 官网 → 优先 SSG，必要时配合 ISR。

TIP

后台 / 用户中心 / 实时业务页 → 优先 SSR。

TIP

高交互工作台 / 图表工具 / 浏览器状态很重 → 优先 CSR（常配合 Client Components）。

TIP

同一页既有稳定块又有慢数据 → 可考虑 Streaming 与 PPR。

13. 总结：先分维度，再谈选型#

如果你觉得这些概念复杂，通常不是因为概念本身难，而是因为我们把不同维度的问题放在一起谈了。

更好的理解方式是：

1. 先问页面内容是构建时生成、请求时生成，还是浏览器里生成
2. 再问组件是在服务端跑还是客户端跑
3. 最后再问是否要增量更新、流式输出、局部预渲染

这样思路就会清楚很多。

14. 对比表#

15. 参考资料#

• Next.js Rendering: https://nextjs.org/docs/app/building-your-application/rendering
• Server and Client Components: https://nextjs.org/docs/app/getting-started/server-and-client-components
• generateStaticParams: https://nextjs.org/docs/app/api-reference/functions/generate-static-params
• generateMetadata: https://nextjs.org/docs/app/api-reference/functions/generate-metadata
• Incremental Static Regeneration: https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration
• Partial Prerendering: https://nextjs.org/docs/app/getting-started/partial-prerendering