1.1 为什么需要Nuxt：从Vue到全栈接力

1.1 为什么需要 Nuxt：从 Vue 到全栈接力

上一章不存在，这就是起点：本节为整本教程建立问题意识——纯客户端渲染到底哪里不够，Nuxt 又补了什么。它直接通向 1.2 的四种渲染模式，也决定了你后面每一章该带着什么疑问去读。读完这节，"要不要上 Nuxt"这个选型问题，你会有一套自己的判断依据。

从一次糟糕的首屏说起

想象一个常见的场景：商品详情页用 Vue 单页应用写成，用户点开链接，浏览器先收到一个几乎空白的 HTML 骨架，然后下载体积不小的 JS 包，解析、执行，组件挂载，再发起数据请求，等接口返回后才画出商品信息。在慢速网络下，用户盯着白屏或加载圈好几秒；如果接口出错，看到的可能是一块空白区域加一行小字。

这不是代码写得差，而是纯客户端渲染（CSR）的固有节奏：HTML 只是张"座位表"，真正的内容要等 JavaScript 到场、执行、取数之后才出现。把这个过程放到接力赛的视角下看，问题一目了然——CSR 让浏览器一个人跑完全程，起跑前的热身（下载并执行 JS）全部计在成绩里。

由此拆出三处短板：

对后台管理系统这类登录后才用、不 care 搜索引擎的场景，这些短板可以忍；但内容型站点、电商详情页、营销页——首屏即价值的地方，就需要请服务器下场跑第一棒了。

服务器第一棒能改变什么

服务端渲染（SSR）的思路直白：浏览器请求到达时，服务器先把组件跑一遍，生成带内容的 HTML 再返回。用户拿到的首份响应里就有商品标题、价格、图片，白屏问题直接消解；爬虫拿到的是完整内容，SEO 有了基础。

// 概念对比：同一段组件代码，两种交付方式
// CSR：浏览器收到 <div id="app"></div>，等待 JS 到场后填充
// SSR：服务器执行组件，返回带内容的 HTML
//   <div id="app"><h1>机械键盘 Pro</h1><p>价格 399 元</p>...</div>
​

注意一个容易忽略的点：SSR 并没有让浏览器闲着。HTML 到达后，浏览器仍要下载同样的 JS、执行、把事件监听挂到已有 DOM 上——这一步叫水合（hydration），是第 4 章的主角。所以 SSR 的本质不是"取代浏览器渲染"，而是分工：服务器管首屏内容，浏览器管交互能力。这正是"交接班"这个词想固定的直觉：一次页面渲染，从来不是一台机器的独角戏。

Vue 之上，Nuxt 多给了什么

Vue 本身通过 createSSRApp 提供了 SSR 的底层能力，理论上你可以手写一个 Node 服务器去用它。但真做过的人都知道，手工拼装要面对一长串工程问题：路由怎么配、每个组件的数据在服务端怎么取、客户端怎么拿到服务端已取的数据避免二次请求、构建产物怎么区分服务端与浏览器、打包后部署到哪种运行时……Nuxt 的价值就是把这些决策预先做好：

「约定优于配置」是理解这张表的钥匙：Nuxt 规定组件放 components 目录就自动注册、页面放 pages 目录就自动有路由。约定看似限制自由，实际是把无限可能性收敛成一条团队都能看懂的结构——新人打开任何 Nuxt 项目，目录即文档。

从版本演进看，这套约定在持续加重：Nuxt 2 时代它更像"SSR 脚手架"；Nuxt 3 引入 Nitro 服务引擎与 Vite 构建后，它已经是全栈框架——你可以在同一个项目里写前端页面和后端接口（第 6 章）；Nuxt 4 进一步整理目录结构（app 子目录收纳前端代码），并强化类型推导。变化很多，但"服务器与浏览器交接班"的主线从第一天稳定至今，这也是本教程敢于用一条接力叙事贯穿全册的原因。

什么项目不该用 Nuxt

工具没有银弹。下面几类项目，引入 Nuxt 的收益可能覆盖不了成本：

• 纯后台工具：内网系统、无 SEO 需求、首屏不敏感，普通 Vue 单页应用更轻；
• 超重交互的应用：在线表格、图形编辑器，几乎每个像素都由交互驱动，服务端渲染的 HTML 会被立即覆盖，第一棒白跑；
• 团队完全无 Node 运维经验且业务简单：SSR 意味着要维护一个常驻服务进程，静态托管几块钱一个月就能解决的宣传页，没必要为此上服务器。

反过来，内容站、电商、需要被搜索收录的 UGC 社区、要兼顾首屏与交互的产品页，都是 Nuxt 的主场。

⚠️ 常见误区：把"用了 Nuxt"等同于"性能自动变好"。SSR 只优化首屏到达时间；JS 包体积失控、图片巨大、接口缓慢这些问题，Nuxt 一样救不了你，第 8 章会专门算这笔账。

从 Vue 单页应用迁移的过渡带

已经有 Vue 单页应用想迁 Nuxt 的团队，不必推倒重来。实践中可行的过渡带分四步：第一步，引入 Nuxt 但全局关闭服务端渲染——迁移路由结构到 pages 目录（路由配置改文件约定），行为与原单页应用一致，这步只动结构不动逻辑；第二步，逐页开启 SSR，从内容型页面开始（关于我们、帮助中心），验证水合无警告后再开核心页面；第三步，把取数逻辑迁到 useAsyncData 体系，享受 payload 免重取；第四步，按 1.2 的选型表配置 routeRules，让该静态的页面静态化。每步都可独立上线验证，风险被切成四份。过渡带里最常见的意外在第二步：老代码里的 window 判断与随机逻辑集中爆发水合警告——这是第 4 章的主场，迁移时预留一段专门处理它们的工期，比压缩进功能迭代里从容得多。

本节要点回顾

• CSR 三短板：首屏慢（内容等 JS）、SEO 弱（爬虫抓不到）、弱网差（串行往返），根因是浏览器独跑全程；
• SSR 是分工不是替代：服务器出首屏 HTML，浏览器水合接管交互，交接班模型由此而来；
• Nuxt 的增量：路由约定、渲染模式切换、两端统一取数、工程化、多目标部署，核心词是约定优于配置；
• 版本主线稳定：从 Nuxt 2 到 4，表面 API 变化大，"服务器与浏览器接力"的底层模型没变；
• 反向选型：后台工具、超重交互、纯静态宣传页，三类项目用 Nuxt 属于高射炮打蚊子。