SSR 渲染策略与选型

发表于 2026-01-12 更新于 2026-02-11 分类于 3-计算机系统，微服务阅读次数： Waline：本文字数： 8.6k 阅读时长 ≈ 8 分钟

服务端渲染 (SSR) 将页面渲染从浏览器前置到服务端，服务器执行组件逻辑并生成完整 HTML 返回给浏览器。本文从 SPA 的痛点出发，梳理主流渲染策略的原理与适用场景，并覆盖缓存、部署、降级等工程实践。

1. 从 SPA 到 SSR：为什么需要服务端渲染

1.1 SPA：单页应用的兴起与瓶颈

SPA (Single Page Application，单页面应用) 是过去十年前端开发的主流架构。React、Vue、Angular 构建的应用默认都属于 SPA。

SPA 的核心特征：

整个应用只有一个 HTML 页面，通过 JavaScript 在浏览器端动态生成和更新内容
路由由前端控制（如 react-router、vue-router），页面切换不触发浏览器全页刷新
前后端通过 API 通信，职责完全分离

SPA 的优势在于交互流畅——页面切换无刷新、体验接近原生应用。但它也带来了两个核心问题：

首屏加载慢：浏览器收到的 HTML 只有一个空的 <div id="app"></div>，必须等待 JS Bundle 下载并执行后才能渲染出内容。在弱网或低端设备上，用户可能面对数秒白屏。
SEO 不友好：搜索引擎爬虫抓取到的是空 HTML，页面内容无法被索引。尽管 Google 爬虫已具备一定的 JS 解析能力，但其他搜索引擎和社交平台（微信、Twitter）的爬虫仍依赖 HTML 中的静态内容。

下图展示 SPA 的加载过程——注意 FCP（首次内容绘制）被推迟到 JS 执行完成之后：

%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#3B82F6', 'actorTextColor': '#1E3A5F', 'actorBorder': '#2563EB', 'signalColor': '#60A5FA', 'activationBkgColor': '#DBEAFE', 'activationBorderColor': '#3B82F6', 'noteBkgColor': '#FEF9C3', 'noteTextColor': '#333'}}}%%
sequenceDiagram
    autonumber
    participant U as "用户浏览器"
    participant S as "静态服务器"
    participant A as "API 服务"

    U->>S: GET /page
    S-->>U: 返回空 HTML（仅含 <div id="app">）

    Note over U: 白屏状态

    U->>S: 请求 JS Bundle（可能数百 KB）
    S-->>U: 返回 JS 文件
    U->>U: 解析、执行 JS
    U->>A: 请求页面数据
    A-->>U: 返回 JSON
    U->>U: 渲染 DOM

    Note over U: FCP：用户终于看到内容

1.2 SSR 如何解决问题

SSR（Server-Side Rendering，服务端渲染）的思路很直接：既然浏览器端渲染慢，就把渲染挪到服务器上。

服务器接收到请求后，执行组件逻辑（React/Vue），生成包含完整内容和结构的 HTML 文档直接返回。浏览器无需等待 JS 即可显示页面内容。

下图展示一次完整的 SSR 请求 - 渲染 - 激活流程，与上面的 SPA 流程对比可以看到 FCP 显著提前：

%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#3B82F6', 'actorTextColor': '#1E3A5F', 'actorBorder': '#2563EB', 'signalColor': '#60A5FA', 'activationBkgColor': '#DBEAFE', 'activationBorderColor': '#3B82F6', 'noteBkgColor': '#FEF9C3', 'noteTextColor': '#333'}}}%%
sequenceDiagram
    autonumber
    participant U as "用户浏览器"
    participant S as "SSR 服务端"
    participant D as "数据层"

    U->>S: GET /page
    activate S
    S->>S: 路由匹配 & 权限校验

    S->>D: 获取页面数据
    activate D
    D-->>S: 返回 JSON
    deactivate D

    S->>S: 执行组件逻辑 -> HTML
    S->>S: 注入脱水数据 (Dehydration)
    S-->>U: 返回完整 HTML + window.__DATA__
    deactivate S

    Note over U: FCP：用户立即看到内容

    U->>U: 加载 JS Bundle
    U->>U: 事件绑定 & 状态接管 (Hydration)
    U-->>U: TTI：页面可交互

SSR 相较于 SPA/CSR 的核心优势：

SEO：爬虫直接获取到完整 HTML 内容，无需执行 JS
首屏性能 (FCP/LCP)：用户在 JS 下载完成前即可看到核心内容，降低跳出率
社交分享：微信、Twitter 等平台的爬虫依赖 HTML 中的 <meta> 标签抓取摘要，SSR 确保动态页面的元数据能被正确识别

理解了 SPA 的痛点和 SSR 的解决思路后，接下来将所有渲染策略放在一起做全景对比。

2. 渲染策略全景

2.1 四种渲染模式

现代 Web 开发中常见四种渲染模式：CSR、SSR、SSG、ISR。它们的核心区别在于渲染发生的时机和位置。

特性	CSR (SPA)	SSR	SSG	ISR
渲染时机	浏览器运行时	请求时 (Runtime)	构建时 (Build Time)	构建时 + 按需更新
首屏性能	慢（依赖 JS 执行）	快（HTML 直出）	最快（预生成静态文件）	快（命中缓存时等同 SSG）
SEO	差	好	好	好
实时性	高（动态 API）	高（实时数据）	低（需重新构建）	中（定时重新生成）
服务器成本	低（静态 CDN 托管）	高（CPU 密集型）	低（静态 CDN 托管）	低 - 中（按需重新生成）
典型框架	Vite, React SPA	Next.js, Nuxt	Hugo, Astro, Gatsby	Next.js (revalidate)
适用场景	管理后台、SaaS 工具	强 SEO、高动态内容	博客、文档、营销页	电商产品页、新闻站

补充几点理解：

CSR 和 SPA 经常混用。严格来说，SPA 是应用架构（单页面、前端路由），CSR 是渲染方式（客户端渲染）。SPA 默认使用 CSR，但也可以结合 SSR（即同构架构）
SSG 在构建阶段就把页面生成为静态 HTML，部署到 CDN 后几乎零服务器开销。但每次内容更新都需要重新构建，对高频更新的内容不友好
ISR 是 Next.js 提出的折中方案，允许在运行时按需重新生成指定页面，兼顾 SSG 的性能和 SSR 的实时性

2.2 同构架构：首屏 SSR + 后续 CSR

同构 (Isomorphic) 是目前主流的 Web 开发范式，核心理念是 “ 一套代码，多端运行 “：

技术栈：Next.js (React)、Nuxt.js (Vue)
运行机制：首屏由服务器 SSR 输出完整 HTML；后续路由跳转接管为 CSR（SPA 模式），兼顾 SEO 与交互体验
工程实践：通常采用 Monorepo 结构，在服务端与客户端之间复用 TypeScript 类型定义与业务逻辑

同构架构本质上是 SSR 和 CSR 的组合——首屏用 SSR 解决性能和 SEO 问题，后续页面切换用 CSR 保持流畅交互。这也是 Next.js、Nuxt.js 的默认工作模式。

同构解决了基本问题，但传统 SSR 仍有性能瓶颈：必须等待所有数据就绪才能响应。现代框架引入了流式传输和组件级拆分来突破这个限制。

3. 工程实践

3.1 缓存策略

SSR 的服务器成本远高于静态托管，缓存是控制成本和提升性能的关键手段。

3.1.1 页面级缓存

对于内容不频繁变化的 SSR 页面，可以在服务端做页面级缓存。常见方式：

// Next.js App Router - 设置缓存策略
// app/products/[id]/page.tsx

export const revalidate = 60; // ISR：每 60 秒重新生成

// 或使用 fetch 级别缓存
async function getProduct(id) {
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: { revalidate: 60 },
  });
  return res.json();
}

3.1.2 CDN 缓存

通过 HTTP 响应头控制 CDN 缓存行为，将 SSR 页面缓存在边缘节点，减少回源请求：

1	Cache-Control: public, s-maxage=60, stale-while-revalidate=300

各字段含义：

s-maxage=60：CDN 缓存 60 秒
stale-while-revalidate=300：缓存过期后 300 秒内，CDN 先返回旧缓存，同时后台回源更新

3.1.3 缓存分层

生产环境通常采用多级缓存：

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#3B82F6', 'primaryTextColor': '#1E3A5F', 'primaryBorderColor': '#2563EB', 'lineColor': '#60A5FA', 'secondaryColor': '#10B981', 'tertiaryColor': '#F59E0B'}}}%%
flowchart LR
    User(["用户请求"]) --> CDN["CDN 边缘缓存"]
    CDN -->|"命中"| R1(["返回缓存页面"])
    CDN -->|"未命中"| App["SSR 应用层"]
    App --> Redis["Redis 页面缓存"]
    Redis -->|"命中"| R2(["返回缓存"])
    Redis -->|"未命中"| Render["执行 SSR 渲染"]
    Render --> R3(["返回 & 写缓存"])

    classDef primary fill:#3B82F6,stroke:#2563EB,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#fff

    class User,R1,R2,R3 primary
    class CDN,Redis success
    class App,Render warning

缓存键的设计需要特别注意：如果页面因用户身份、地区、设备类型不同而呈现不同内容，缓存键必须包含这些维度，否则会导致缓存污染——A 用户看到 B 用户的个性化内容。

3.2 部署方案

SSR 应用需要运行 Node.js 进程，部署方式比静态站点复杂。常见三种方案：

方案	适用场景	优势	劣势
Node.js 集群	传统部署、自建机房	控制力强，可精细调优	需要自行管理进程、扩容
Docker 容器化	K8s 环境、团队有容器化经验	环境一致，水平扩展方便	冷启动有延迟
Serverless / Edge	流量波动大、全球化业务	按需付费，零运维	冷启动问题，运行时限制

Docker 容器化部署示例（Next.js）：

# 多阶段构建，减小镜像体积
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public

EXPOSE 3000
CMD ["node", "server.js"]

Next.js 的 output: 'standalone' 配置会生成独立部署包，镜像体积可控制在 100MB 以内。

Edge SSR 是近年趋势，将 SSR 逻辑部署到 CDN 边缘节点（如 Cloudflare Workers、Vercel Edge Functions）。优势是用户请求就近处理，延迟极低；限制是运行时不完整，不支持所有 Node.js API。

3.3 降级与错误处理

SSR 在生产环境中必须考虑服务端渲染失败的情况：组件运行时错误、数据源超时、内存不足等。核心原则是 SSR 失败不应导致页面白屏，而是降级到 CSR。

降级策略的基本逻辑：

// 简化的 SSR 降级示例
async function handleRequest(req, res) {
  try {
    // 尝试 SSR 渲染
    const html = await renderToString(<App />);
    res.send(html);
  } catch (error) {
    console.error('SSR failed, falling back to CSR:', error);
    // 降级：返回空壳 HTML，由客户端 JS 接管渲染
    res.send(`
      <!DOCTYPE html>
      <html>
        <head><title>Page</title></head>
        <body>
          <div id="app"></div>
          <script src="/client-bundle.js"></script>
        </body>
      </html>
    `);
  }
}

生产环境的完整降级方案还需要考虑：

超时控制：为 SSR 渲染设置超时时间（通常 3-5 秒），超时自动降级
熔断机制：当 SSR 错误率超过阈值时，自动切换到 CSR 模式，避免雪崩。错误率恢复后自动切回 SSR
监控告警：记录 SSR 降级事件的频率和原因，便于排查问题

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#3B82F6', 'primaryTextColor': '#1E3A5F', 'primaryBorderColor': '#2563EB', 'lineColor': '#60A5FA', 'secondaryColor': '#10B981', 'tertiaryColor': '#F59E0B'}}}%%
flowchart TD
    Req(["用户请求"]) --> SSR{"SSR 渲染"}
    SSR -->|"成功"| OK(["返回完整 HTML"])
    SSR -->|"失败/超时"| CB{"熔断器状态"}
    CB -->|"关闭（正常）"| CSR(["降级：返回 CSR 壳"])
    CB -->|"打开（熔断中）"| CSR
    CSR --> Log["记录降级事件"]
    Log --> Monitor["监控: 降级率 / 原因分析"]

    classDef primary fill:#3B82F6,stroke:#2563EB,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#fff
    classDef danger fill:#EF4444,stroke:#DC2626,color:#fff

    class Req,OK primary
    class SSR,CB warning
    class CSR danger
    class Log,Monitor success

4. 框架对比与选型

4.1 主流框架横向对比

特性	Next.js	Nuxt 3	Remix	Astro
底层框架	React	Vue 3	React (React Router)	框架无关（React/Vue/Svelte）
渲染模式	CSR / SSR / SSG / ISR / RSC	CSR / SSR / SSG / ISR	SSR / CSR	SSG（默认）/ SSR（可选）
核心理念	全功能 React 框架	Vue 全栈框架	Web 标准优先	内容优先，少 JS
RSC 支持	原生支持 (App Router)	不支持	不支持	不适用
流式 SSR	支持（React 18）	支持	原生支持	支持
Islands	不原生支持	不原生支持	不支持	核心特性
部署目标	Node.js / Serverless / Edge	Node.js / Serverless / Edge	Node.js / Serverless	静态 / Node.js / Edge
上手难度	中（概念多）	低（Vue 开发者友好）	中（需理解 Web 标准）	低
生态成熟度	最成熟，Vercel 官方维护	成熟，Vue 官方维护	成长中，Shopify 维护	成长中
最佳场景	复杂 Web 应用、SaaS	Vue 技术栈全栈应用	数据密集型 Web 应用	博客、文档、营销站

选型建议：

团队使用 React 且需要全功能方案 → Next.js
团队使用 Vue → Nuxt 3
对 Web 标准有追求、数据驱动的应用 → Remix
内容为主、交互为辅的站点 → Astro