1.2 四种渲染模式与棒次安排

1.2 四种渲染模式与棒次安排

承接 1.1 的结论——需要服务器下场跑第一棒——本节把"怎么跑"的方案空间铺开：SSR、SSG、CSR、混合渲染四种模式，本质是四种棒次安排。它为第 3 章的渲染实践与 routeRules 配置提供选型基础，也是你日后评估任何页面"该怎么渲染"的通用框架。

用三个问题给模式分类

抛开术语，任何渲染模式都能被三个问题定位：

1. 谁来生成 HTML？——服务器、构建机，还是浏览器；
2. 什么时候生成？——请求到达时、构建发布时，还是页面加载后；
3. 数据什么时候取？——和 HTML 同一轮、构建时，还是到浏览器再取。

SSR 的答案是"服务器、请求时、同轮取"：内容最新鲜，代价是每请求都要跑渲染，服务器有压力。SSG（静态站点生成）把渲染提前到构建时：发布前把所有页面跑成 HTML 文件，请求来了直接回静态文件，速度最快、托管最便宜，但内容更新要重新构建——商品价格这种分钟级变化的信息就扛不住。CSR 则是"浏览器、加载后、到端再取"：回到 1.1 分析过的独跑模式。混合渲染是导演角色：同一站点里，不同路由用不同模式。

图 1-1：四种渲染模式的棒次对比

各模式的工程细节

SSR。每请求渲染一次，服务器 CPU 是主要成本；页面内容与数据强一致。要点在于"水合"这步交接——浏览器拿到 HTML 后还要执行 JS 把静态内容变成可交互的，若两端渲染结果不一致就会报水合错误（第 4 章展开）。

SSG。构建时跑爬取（crawling）确定页面清单：从首页出发，沿着链接把所有路由渲染成 HTML。数据在构建时锁定，适合文档、博客、营销页。Nuxt 里把渲染模式关掉、执行 generate 命令即得全静态产物，托管在任意静态服务器或对象存储即可。

ISR（增量静态再生）介于两者之间：首次请求生成并缓存静态页，之后请求直接命中缓存，同时按设定的间隔在后台重新生成。商品页这种"数据分钟级变、单页访问量大"的场景最合适。Nuxt 3 的 routeRules 里给路由标 isr 并配间隔即可。

CSR/SPA 模式。在 Nuxt 里并不意味着退回手工时代：你可以对单条路由关闭服务端渲染（ssr: false），首页会先输出一个带加载状态的壳，由客户端完成渲染。后台管理、登录后区域常用这招——省掉服务器渲染开销，又不破坏整站结构。

// nuxt.config.ts 中按路由分配模式（第3章将逐项展开）
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },               // 首页：构建期静态化
    '/docs/**': { isr: 3600 },              // 文档：ISR，每小时再生
    '/product/**': { swr: 600 },            // 商品：缓存十分钟的后台再生
    '/admin/**': { ssr: false },            // 后台：纯客户端渲染
  },
})
​

这段配置值得盯着看一会儿——四种模式同时出现在一个站点里，每条路由一行，这就是"混合渲染"的全部表面复杂度。

选型判断表

从历史看模式之争

这四种模式没有一种是新发明，它们是同一场钟摆运动的不同刻度。最早的 Web 全是"服务端渲染"——CGI 与 PHP 时代，每个请求都由服务器拼出完整 HTML 返回。单页应用兴起后，钟摆荡到另一头：服务器只发骨架，渲染全归浏览器，换来了流畅的交互体验，代价是 1.1 列出的三短板。所谓"现代 SSR 框架"，本质是钟摆回摆时带着单页应用积累的组件化与工程化成果一起回来：既要有服务器的首屏与 SEO，又不能丢掉客户端的交互体验——混合渲染正是这个"都要"诉求的工程化答案。理解这段钟摆史，你就明白为什么各模式不是替代关系而是并存关系：它们各自站在体验、成本、新鲜度三角的不同位置上。

模式选择还是个团队问题。全静态方案对后端能力要求最低，前端团队独立可维护；重 SSR 方案需要有人懂 Node 运维、懂缓存、懂排错。选型会上技术负责人常高估团队对"多一个常驻服务"的承受力——服务器崩了半夜要不要起来看，这个问题比"哪个模式更快"重要得多。

常见疑问

问：SSR 的页面是不是一定比 CSR 快？
不是。SSR 优化的是"首屏内容到达时间"（内容随 HTML 直达），但服务器渲染本身要花时间（TTFB 变长），接口慢的 SSR 页面可能比轻量 CSR 页面更慢。SSR 的快是有条件的：服务端渲染链路要短、缓存要用足。第 8 章会看到，一个接口拖沓的 SSR 页面在 Lighthouse 上照样红。

问：上 SSG 之后内容怎么更新？
两条路：整站重新构建发布（内容低频时最简单，流水线自动化后成本可控）；或对高频变化的路由改用 ISR/SWR，让缓存按间隔再生。混合渲染的价值就在这里——不必整站二选一。

问：一个页面能同时用两种模式吗？
能，而且很常见：页面主体 SSR 保证首屏与 SEO，页面里某块个性化内容（比如"猜你喜欢"）用客户端取数（useAsyncData 的 server:false 或 lazy）。模式是路由级与数据级都可以做的决策，粒度比想象中细。

⚠️ 常见坑：把整站一刀切设成 SSR，结果静态文档页也在消耗服务器渲染资源。先用这张表过一遍路由清单，往往能砍掉大半渲染开销。

💡 关键直觉：模式选择不是技术问题而是业务问题——问"这页内容多久变一次、要不要被搜索到、流量多大"，答案自动浮现。

本节要点回顾

• 三问定位法：谁生成 HTML、何时生成、数据何时取，可给任何渲染模式归类；
• SSR 请求时渲染，内容最新、占服务器；SSG 构建时定稿，最快最省、更新要重建；ISR 首访缓存加定时再生，居中；
• 混合渲染 是 Nuxt 的杠杆点：routeRules 让模式成为每条路由的属性，而非整站的宿命；
• 选型看业务：变化频率、SEO 需求、流量规模三要素决定模式，与代码难度无关。