很多团队第一次认真考虑SSR或SSG，并不是因为技术趋势，而是遇到了实实在在的业务瓶颈：一个用Vue CSR写的官网，市场部抱怨在搜索引擎里怎么也搜不到核心产品页；一个电商列表页，因为首屏加载慢了几百毫秒，转化率数据就是上不去。渲染模式不再是一个可选的“优化项”，而是直接关系到核心业务指标的“架构基础”。

四种模式的核心逻辑与运行时行为

要做出正确选择，首先得抛开那些模糊的类比，从工程视角理解它们各自在何时、何地、以何种成本完成渲染工作。

CSR：把渲染责任完全交给浏览器

这是最经典的单页应用（SPA）模式。服务器只提供一个极简的HTML外壳和一个庞大的JavaScript包。当用户访问时，浏览器需要先下载、解析、执行整个JS应用，然后应用才开始发起数据请求，最终将内容渲染到DOM中。

// 一个典型的CSR组件数据获取
'use client'
import { useEffect, useState } from 'react';

function ProductPage() {
  const [product, setProduct] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/product/123')
      .then(res => res.json())
      .then(data => {
        setProduct(data);
        setLoading(false);
      });
  }, []);

  if (loading) return 
加载中...
;
  return 
{product.name}
;
}

它的优势在于开发体验流畅，前后端彻底分离，且页面内的交互极其迅速。但代价是首屏性能：用户会先看到一个空白页面或加载动画，等待时间取决于网络速度和客户端设备性能。对于依赖搜索引擎流量的页面，这也是一个致命伤。

SSR：每次请求都在服务端即时生成HTML

为了解决CSR的问题，SSR将渲染工作提前到了服务器。对于每个到达的请求，Node.js服务器（或类似环境）会执行你的前端应用代码，获取必要数据，生成完整的HTML字符串，然后将其发送给浏览器。浏览器收到后能立即展示内容，之后再加载JS进行“水合”，接管后续的交互。

真正的麻烦往往不在原理，而在落地。你需要一个能够运行Node.js的服务器环境，这意味着更高的运维复杂度和成本。同时，如果数据库查询或下游API变慢，会直接拖累整个页面的响应时间，因为用户必须等待服务器完成所有工作。

SSG：在构建时一劳永逸地生成静态文件

如果页面内容不经常变化，为什么每次请求都要渲染呢？SSG就是这个思路的极致体现。在项目构建（build）阶段，它会预先获取所有数据，为每一个可能的路径生成对应的HTML文件。这些纯静态文件可以直接部署到CDN上。

它的性能是天花板级别的：CDN边缘节点直接返回文件，几乎没有计算延迟。服务器成本和运维复杂度也降到最低。但它的限制也很明显：无法处理需要实时数据或用户个性化内容的页面。每次内容更新，都需要触发一次完整的重新构建和部署。

ISR：为静态站点注入动态更新的能力

ISR可以看作是SSG的“智能升级版”。它首先在构建时生成静态页面。但在页面被访问时，或按照预设的时间间隔，它可以在后台异步地重新生成这个页面，并用新版本替换旧的静态文件。下次访问时，用户就能看到更新后的内容。

// Next.js 中 ISR 的配置示例
export const revalidate = 60; // 每60秒最多重新验证一次

async function getProductData(id) {
  const res = await fetch(`https://api.example.com/products/${id}`);
  return res.json();
}

export default async function Page({ params }) {
  const product = await getProductData(params.id);
  // 页面首次构建或60秒后再次访问时，会尝试在后台获取新数据并重新生成
  return 
{product.name}
;
}

这巧妙地平衡了性能与实时性。对于新闻网站，你可以将首页设置为每30秒再生，既保证了绝大多数访问的极速响应，又能让内容保持相对新鲜。

横向对比：性能、成本与适用性的多维权衡

脱离场景谈优劣没有意义。下面的表格从几个关键维度对比了这四种模式，这能帮助你在技术讨论时有一个共同的基准。

真实场景下的选型决策框架

知道了它们是什么，接下来是关键的一步：怎么选？我建议从以下几个问题出发，进行团队内的评估：

1. 内容的变化频率有多高？

• 几乎不变（如公司官网、产品文档、博客文章）：优先考虑SSG。它的性能和成本优势太大，没有理由不用。使用像VitePress、Docusaurus或Next.js的静态导出功能。
• 定期更新（如新闻门户、商品列表）：ISR是最佳拍档。为首页、列表页设置一个合理的再验证时间（如60秒），就能在性能和新鲜度间取得完美平衡。
• 实时/个性化（如社交信息流、用户仪表盘、交易页面）：这类页面每个用户看到的内容都不同，且数据时刻在变。你需要SSR来为每个请求即时组装页面，或者采用CSR（如果对首屏SEO要求不高）。

2. 搜索引擎优化（SEO）是否至关重要？

如果网站流量严重依赖Google、百度等搜索引擎，那么CSR基本可以排除在外。虽然现代爬虫执行JavaScript的能力在增强，但其可靠性和及时性仍不如直接获取完整的HTML。SSR和SSG/ISR都是SEO友好的选择，区别在于SSR能保证内容绝对最新，而SSG/ISR的性能更优。

3. 团队的运维能力与基础设施如何？

这是很多纯前端团队容易低估的一点。选择SSR，意味着你需要：

• 维护一个高可用的Node.js服务器集群。
• 设置负载均衡和监控。
• 处理服务器端的内存泄漏、冷启动延迟等问题。
• 设计合理的缓存策略（缓存什么？缓存多久？如何清除？）。

如果你的团队没有后端或运维经验，贸然上马SSR可能会让项目后期举步维艰。这时，SSG（托管在Vercel、Netlify等平台上）或CSR可能是更稳妥的起点。

混合模式：现代框架的实践答案

幸运的是，我们不必在全站范围内只做单一选择。以Next.js、Nuxt.js为代表的现代元框架，其核心价值之一就是支持“混合渲染”。你可以在同一个项目中，针对不同的路由采用不同的渲染策略。

想象一个电商网站：

• 营销落地页（/promo/black-friday）：内容固定，访问量巨大。使用SSG，享受CDN的极致速度。
• 商品列表页（/products）：商品可能上下架，但频率不高。使用ISR，每10分钟再生一次，平衡性能和新鲜度。
• 商品详情页（/product/[id]）：库存、价格需实时。使用SSR，确保用户看到准确信息。
• 用户购物车（/cart）：高度个性化，且对SEO无要求。使用CSR，提供流畅的交互体验。

这种按需分配的策略，使得架构能够紧密贴合业务需求，在性能、功能和成本之间找到最佳结合点。

从技术选型到落地避坑

确定了方向，在实施阶段还有一些常见的“坑”需要注意：

• 水合不匹配（Hydration Mismatch）：主要发生在SSR中。如果服务端和客户端渲染出的初始DOM结构不一致，React等框架会抛出警告并强制在客户端重新渲染，导致性能损耗。确保两边使用的数据、组件逻辑完全一致。
• SSR下的数据获取：避免在客户端组件（如useEffect）中获取首屏关键数据，那会退化回CSR。应使用框架提供的服务端数据获取方法（如Next.js的`getServerSideProps`或`async`组件）。
• ISR的兜底策略：当访问一个尚未生成或正在再生的页面时，你需要决定是返回一个“加载中”的fallback页面，还是阻塞等待生成完成。Next.js的`fallback: true | false | ‘blocking’`选项就是用来处理这个场景的。
• 缓存策略的复杂性：混合模式下，缓存变得多层且复杂。你需要清楚浏览器缓存、CDN缓存、服务器缓存（对于SSR）、以及ISR的再生缓存各自的作用域和失效机制。

总结：回归业务本质的架构思维

选择渲染模式，本质上是在回答一系列关于你业务的问题：你的用户是谁？他们最在意什么？你的内容如何产生和变化？你的团队擅长什么？

没有一种模式是银弹。当前的主流趋势是“静态优先，动态补充”——尽可能利用SSG/ISR获得最佳性能和最低成本，只在必要的地方引入SSR的动态能力。同时，随着边缘计算平台的成熟，将SSR逻辑运行在离用户更近的CDN边缘节点（边缘渲染），正在成为解决SSR延迟和扩展性问题的新方向。

建议你在项目初期，就用一个简单的决策矩阵来对齐团队认知。当性能、SEO、开发效率和运维成本这几个维度被摊开讨论时，技术选型就不再是个人偏好，而是一个支撑业务目标的理性决策。