Nuxt渲染模式详解：SSR、SSG、CSR与混合渲染怎么选

本节目标：理解 SSR、SSG、CSR、混合渲染四种模式各自怎么工作、优缺点是什么，并能根据场景选对模式。

「渲染」指的是：把 Vue 组件变成浏览器能显示的 HTML 元素这件事。浏览器和服务端都能跑 JavaScript，所以这件事可以在「服务端」做，也可以在「浏览器（客户端）」做。Nuxt 支持多种渲染模式，理解它们的差异，是做好一个 Nuxt 项目的基础。

8-1

Nuxt 默认用的是通用渲染（Universal Rendering），底层就是服务端渲染（SSR，Server-Side Rendering）。流程是这样的：

浏览器请求一个 URL。
Nuxt 在服务端执行你的 Vue 代码，生成一份完整的 HTML 直接返回。
浏览器立刻显示内容——用户不用等 JS 下载完就能看到页面。
HTML 下载后，Vue 在浏览器里「再次」运行同一套代码，把静态 HTML 接管过来、绑定事件，让它变得可交互。这一步叫 hydration（水合）。

正因为「服务端画一次 + 客户端再激活一次」，所以叫通用渲染——两端都参与了。

SSR 的优点很实在：

首屏快：用户马上看到内容，比等 JS 跑完再出界面快得多。
SEO 好：搜索引擎爬虫拿到的是现成 HTML，不用等 JS 执行就能索引内容，利于被搜到。
低性能设备友好：减少了浏览器要下载执行的 JS 量。
可访问性好：内容一加载就存在，对读屏软件等辅助技术更友好。

代价也有：需要跑一个服务端来动态生成页面，带来一定成本；而且写代码时要留意「哪些代码只在浏览器跑」（比如访问 window 对象的代码不能放服务端）。

Note

一个常见疑问：<script setup> 里的代码，哪些在服务端、哪些在客户端？简单说，初始化（如 ref(0)）两端都跑；而事件处理函数（如点击按钮才执行的逻辑）只在浏览器跑。Nuxt 提供了变量帮你判断当前环境。

8-2

传统 Vue 应用默认是客户端渲染（CSR，Client-Side Rendering）：浏览器先下载一整包 JS，等它解析执行完，才由 Vue 生成 HTML。在 JS 跑完之前，页面是空白的（只有一个空容器）。

优点：

开发简单：不用操心代码的服务端兼容性，放心用 window、本地存储等浏览器 API。
成本低：纯静态托管即可，不需要服务器。
可离线：代码全在浏览器，断网也能跑（已加载后）。

缺点：

首屏慢：必须等 JS 下载、解析、执行，弱网或低端设备体验差。
SEO 弱：爬虫第一次来时界面还没渲染，内容索引和更新都慢。

适合需要重度交互、又不太在乎被搜索引擎收录的应用，比如后台管理系统、SaaS 控制台、在线游戏。

在 Nuxt 里全局关闭 SSR，只需一行：

export default defineNuxtConfig({
  ssr: false,
})

Warning

用 ssr: false 时，建议在根目录放一个 spa-loading-template.html，在应用水合完成前显示加载界面，否则用户会看到一段空白期。纯 SPA 不是 Nuxt 的强项，按需使用。

8-3

SSG（Static Site Generation）是 SSR 的「预渲染版」：不是在用户请求时才渲染，而是在构建阶段就把每个页面渲染成静态 HTML 文件。上线后这些文件直接由 CDN 分发，速度极快、成本极低。

在 Nuxt 里用 nuxt generate 实现（第 6 章讲过）。它适合内容相对固定的站点：官网、博客、文档、作品集。

8-4

现实项目往往「有的页面要静态、有的要动态」。比如一个内容站：文章页可以提前生成，后台管理页却是动态应用。混合渲染（Hybrid Rendering）用 routeRules 给不同路由分别指定策略：

export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },          // 首页构建时预渲染
    '/products/**': { swr: 3600 },      // 产品页按需生成，缓存 1 小时
    '/blog/**': { isr: true },          // 博客页增量静态再生
    '/admin/**': { ssr: false },        // 后台仅客户端渲染
  },
})

常用规则字段：

prerender：构建时预渲染该路由。
ssr：是否服务端渲染。
swr / isr： stale-while-revalidate / 增量静态再生，先返回缓存、后台重新生成。
cors、redirect、headers 等：附加行为。

Tip

注意 nuxt generate（纯静态）模式下混合渲染不可用——因为生成产物里没有服务端去执行这些规则。要在静态托管上做混合，需配合支持 ISR 的平台（如 Vercel、Netlify）。

8-5

边缘渲染（Edge-Side Rendering）更像一种「部署目标」而非独立模式：借助 Nitro，Nuxt 可以把渲染放到 CDN 的边缘节点上，让离用户最近的服务器生成 HTML，降低延迟。它常与混合渲染、路由规则组合使用，可部署到 Cloudflare、Vercel Edge、Netlify Edge 等。

8-6

你的站点	推荐模式	配置方式
内容站、电商、营销页（要 SEO、要快）	SSR（默认）	不改，默认即 SSR
官网、博客、文档（内容固定）	SSG	`nuxt generate`
后台、SaaS、游戏（重交互、不care SEO）	CSR	`ssr: false`
混合需求（部分静态部分动态）	混合渲染	`routeRules`

Note

Nuxt 默认选 SSR，是因为它对「既想要快首屏、又想要好 SEO、还要保留交互」的大多数网站是最稳的折中。你随时可以按需切换，不用一开始就纠结。

8-7

SSR 是 Nuxt 默认，服务端先出 HTML、浏览器再水合，兼顾速度与 SEO；CSR 只在浏览器画，简单但 SEO 弱；SSG 构建时一次性画好，适合静态内容；混合渲染用 routeRules 给不同路由定制策略。选模式看场景，不必死守一种。

8-6 混合渲染策略的选择

在实际项目中，纯 SSR 和纯 SSG 往往不是最优解。很多站点会采用混合策略：营销页面、文档页面用 SSG 预渲染，因为它们内容稳定、访问量大；用户中心、订单详情这类动态页面用 SSR 实时渲染，因为它们依赖实时数据。

Nuxt 的 routeRules 让你可以在 nuxt.config.ts 里按路由粒度指定渲染策略。比如把 /blog/** 设为预渲染，把 /dashboard/** 设为 SSR。这种灵活性是 Nuxt 相比纯前端框架的一大优势。

选择渲染策略时，核心考虑两个维度：内容的更新频率和 SEO 的重要性。更新频率低且 SEO 重要的页面优先 SSG；更新频率高或需要实时数据的页面用 SSR；完全不需要 SEO 的页面（如后台管理）可以用 SPA 模式减轻服务器负担。

8-7 不同渲染模式对开发体验的影响

渲染模式不仅影响上线后的表现，也会影响开发时的体验。SSR 模式下，开发服务器的启动速度会比纯 SPA 稍慢，因为服务端需要额外处理渲染逻辑。但 Nuxt 的开发服务器已经做了大量优化，这种差异通常在可接受范围内。

SSG 模式下，开发时的体验和 SSR 几乎一样，区别只在构建阶段。你可以放心在开发时用 SSR 模式调试，上线时切换到 SSG，不需要改任何代码。SPA 模式的开发体验最接近传统前端项目，启动快、热更新迅速，但上线后没有服务端渲染的优势。