把 Nuxt 一次性
讲到骨架里

00它到底是什么

一句话：Nuxt 是建立在 Vue 之上的"全栈元框架"（meta-framework）。Vue 解决的是"一个页面里的组件怎么渲染、怎么响应数据变化"；而 Nuxt 解决的是 Vue 自己不管的那一整圈工程问题。

当你只用 Vue（哪怕加上 Vue Router、Pinia）时，你仍然要自己回答一堆问题：路由文件怎么组织？要不要服务端渲染（SSR）？SSR 时怎么把数据从服务端"搬"到客户端而不重复请求？打包构建怎么配？SEO 怎么办？部署到 Vercel / Cloudflare / Node 服务器要不要改代码？Nuxt 把这些问题用一套"约定 + 运行时 + 构建工具"打包成了默认答案。

它最关键的三个身份要同时记住，面试常考：

• 它是个约定式框架（convention over configuration）——你把文件放进 pages/，路由就自动生成；放进 server/api/，API 就自动注册。目录结构本身就是配置。
• 它是个同构 / 通用框架（isomorphic / universal）——同一份组件代码既在 Node 服务端跑一次（生成 HTML），又在浏览器跑一次（接管交互）。这是理解 Nuxt 一切"坑"的总钥匙。
• 它是全栈的——内置了一个完整的服务端引擎 Nitro，你能写后端 API、中间件、定时任务，而不只是前端。

Nuxt 3 vs Nuxt 4：你需要知道的差异

Nuxt 4 于 2025 年 7 月发布，是一次"稳定性导向"的演进而非重写，从 3 升级非常平滑。当前（2026 年中）稳定线是 4.4.x。面试里如果提到版本差异，记住这几条最大的变化：

01核心心智模型：一切从"代码跑两遍"开始

如果你只带走一个概念，就是这个。Nuxt 默认是 SSR（服务端渲染） 模式，意味着你写的同一段组件代码会在两个完全不同的环境各执行一次。

这套机制叫 同构渲染（isomorphic / universal rendering）。它带来三个你必须时刻警惕的事实，几乎每个 Nuxt bug 都能追溯到它们：

1. 服务端没有浏览器 API。 window、document、localStorage 在 Node 端不存在。在组件顶层直接访问它们会让 SSR 崩溃。解决方案：放进 onMounted（只在客户端跑），或用 import.meta.client 判断。
2. 数据不能请求两遍。 服务端为了渲染 HTML 已经拉过一次数据，如果客户端水合时又拉一遍，既浪费又可能闪烁。Nuxt 用 payload 机制把服务端数据"腌制"后随 HTML 一起发给客户端，客户端直接复用——这正是 useAsyncData/useFetch 存在的根本理由。
3. 水合必须一致。 服务端生成的 DOM 结构必须和客户端首次渲染的结构一模一样，否则报 hydration mismatch。所以不能在渲染里用 Math.random()、Date.now() 这类两端结果不同的东西。

<script setup>
// ❌ 服务端崩溃
// const width = window.innerWidth

// ✅ 方案一：仅客户端逻辑放进 onMounted
const width = ref(0)
onMounted(() => { width.value = window.innerWidth })

// ✅ 方案二：环境分支（编译期会被 tree-shake）
if (import.meta.client) {
  // 只在浏览器执行
}
</script>

import.meta.server 与 import.meta.client 是 Nuxt 注入的编译期常量，构建时会把不属于当前环境的分支整段删掉（dead-code elimination），所以它既是运行时判断也是打包优化手段。

02整体架构设计：三根支柱撑起一切

Nuxt 本身几乎不"造轮子"。它的架构本质是一个编排层，把三个独立的、各自强大的工具拼成一个连贯的全栈体验。把这三根支柱的分工记牢，你就理解了 80% 的架构。

支柱一 · Vue 3 —— 渲染与响应式

Nuxt 不改 Vue 的渲染逻辑。组件、ref/reactive 响应式、<script setup>、组合式 API 全都是原生 Vue。Nuxt 做的是：决定 Vue 应用在哪里、何时被实例化——服务端用 createSSRApp 渲成字符串，客户端再 createApp 挂载并接管。它还内置了 Vue Router，但路由表不是你手写的，而是从 pages/ 目录扫出来的。

支柱二 · Vite —— 构建与开发服务器

Vite 负责开发时的极速热更新（基于原生 ESM + esbuild），以及生产打包（底层用 Rollup）。Nuxt 在 Vite 上叠加了大量插件来实现自动导入、组件自动注册、虚拟模块等"魔法"。关键点：Nuxt 4 时代是一份代码、两套构建产物——一套给浏览器（client bundle），一套给 Node/Nitro（server bundle）。

支柱三 · Nitro —— 服务端引擎（最容易被低估）

这是 Nuxt 3+ 相对 Nuxt 2 最大的架构升级。Nitro 是一个独立的、与平台无关的服务端运行时。它负责：

• 运行 SSR（执行 server bundle 生成 HTML）；
• 把 server/api/、server/routes/ 里的文件编译成真正的 HTTP 接口；
• 底层用 h3（一个极轻量的 HTTP 框架）处理请求，用 unjs 生态（unstorage 做存储抽象、ofetch 做请求）；
• "一次编写，处处部署"——同一份 Nitro 应用能通过切换 preset 打包成 Node server、Vercel/Netlify 函数、Cloudflare Workers、静态站点，无需改业务代码。这是面试加分点。

四层心智图：从你的代码到用户屏幕

03目录约定即架构（这是 Nuxt 的"源代码"）

在 Nuxt 里，目录结构不是组织习惯，而是真正的运行规则。把文件放进特定目录，等于在向框架注册行为。理解每个目录的含义，几乎等于理解 Nuxt 的运行机制。Nuxt 4 起，应用代码统一放在 app/ 下。

my-nuxt-app/
├─ app/                  # ★ Nuxt4 新增：应用源码根
│  ├─ app.vue            # 应用根组件（整棵树的入口）
│  ├─ error.vue          # 全局错误页
│  ├─ pages/             # 文件 → 路由（自动生成路由表）
│  │   ├─ index.vue      # 路由 /
│  │   ├─ about.vue      # 路由 /about
│  │   └─ users/[id].vue # 动态路由 /users/:id
│  ├─ components/        # 自动注册，无需 import
│  ├─ layouts/           # 页面外壳（导航/页脚等共享框架）
│  ├─ composables/       # 自动导入的组合式函数
│  ├─ middleware/        # 路由中间件（导航守卫）
│  ├─ plugins/           # 应用启动时运行的插件
│  └─ utils/             # 自动导入的工具函数
├─ server/               # ★ Nitro 服务端（独立于 app/）
│  ├─ api/hello.ts       # → GET/POST /api/hello
│  ├─ routes/            # 非 /api 前缀的服务端路由
│  ├─ middleware/        # 服务端中间件（每个请求都跑）
│  └─ plugins/           # Nitro 插件
├─ public/               # 原样暴露的静态资源（/favicon.ico）
├─ assets/               # 需经构建处理的资源（scss/图片）
├─ modules/              # 本地 Nuxt 模块
├─ nuxt.config.ts        # 唯一的全局配置入口
└─ package.json

插件后缀的环境约定

插件文件名可以用后缀控制运行环境，这是高频细节：

• plugins/foo.client.ts —— 只在浏览器运行（适合接入只有客户端的库，如图表、地图）；
• plugins/foo.server.ts —— 只在服务端运行；
• plugins/foo.ts —— 两端都运行。

04模块系统与 Nuxt Kit：可扩展性的底座

Nuxt 的整个生态（@nuxt/image、@pinia/nuxt、@nuxtjs/i18n…）都建立在模块系统之上。模块是在构建期运行的函数，能修改配置、注入组件、添加运行时代码、扩展 Nitro。理解它能让你回答"Nuxt 怎么做到生态如此繁荣"。

核心区分（面试常混淆）：

// 一个最小模块：注册一个运行时插件 + 暴露配置
import { defineNuxtModule, addPlugin, createResolver } from '@nuxt/kit'

export default defineNuxtModule({
  meta: { name: 'my-module', configKey: 'myModule' },
  defaults: { greeting: 'hi' },
  setup(options, nuxt) {
    const { resolve } = createResolver(import.meta.url)
    // 在构建期把一个插件塞进应用
    addPlugin(resolve('./runtime/plugin'))
    // 把配置塞进运行时可读的 runtimeConfig
    nuxt.options.runtimeConfig.public.myModule = options
  }
})

构建期钩子（hooks）

Nuxt 在构建和运行的关键节点暴露了大量钩子，模块通过监听钩子介入流程。常见的有 pages:extend（路由表生成后）、nitro:config（Nitro 配置就绪）、build:before 等。这套钩子机制（基于 unjs 的 hookable）是 Nuxt 可扩展性的神经系统。

05请求生命周期：一个请求从进门到出门

这是面试最爱问的"原理题"。把一次首屏 SSR 请求拆成阶段，你能讲清楚每一步发生了什么、你写的哪段代码在哪一步介入。

几个关键洞察：

• 第 ⑤ 步是数据流的核心。 SSR 会 await 你的 useAsyncData，确保 HTML 里已经带着数据返回——这才是 SSR 对 SEO 有利的原因（爬虫拿到的是有内容的 HTML，而非空壳）。
• 第 ⑥→⑨ 步靠 payload 串联。 服务端拉到的数据被序列化进 HTML，客户端水合时直接读，避免二次请求。这是 §11 数据流的主线。
• 插件分两端跑两次（除非加 .server/.client 后缀）。 路由中间件也有 SSR 端和客户端端的差别。

中间件的两个世界

// app/middleware/auth.ts —— 路由中间件示例
export default defineNuxtRouteMiddleware((to, from) => {
  const user = useUserState()        // 共享状态
  if (!user.value && to.path !== '/login') {
    return navigateTo('/login')    // 返回即重定向
  }
})

06同构与水合：Nuxt 最难也最高频的考点

"水合"（hydration）是把服务端发来的静态 HTML"激活"成可交互 Vue 应用的过程。讲清楚它，面试官基本就认定你懂 SSR 了。

为什么需要水合

服务端发来的 HTML 是死的——按钮点了没反应，因为它只是字符串。客户端拿到后，Vue 会再渲染一遍组件树，然后不重建 DOM，而是把事件监听器、响应式系统"附着"到已有的 DOM 节点上。这个"附着"动作就是水合。它比客户端从零渲染快，因为 DOM 已经在那了。

Hydration Mismatch（水合不匹配）

核心规则：服务端渲染出的 DOM 必须与客户端首次渲染的 DOM 完全一致。一旦不一致，Vue 报警告并丢弃服务端 DOM、强制客户端重渲，性能与体验双输。常见诱因：

• 渲染中使用两端不同的值：Date.now()、Math.random()、new Date() 直接输出；
• 根据 window/屏幕宽度在渲染期决定结构（服务端没有 window，默认值与客户端不同）；
• 第三方库在两端输出不同 HTML；
• 无效的 HTML 嵌套（如 <p> 里塞 <div>，浏览器会自动纠正导致结构变化）。

<template>
  <!-- 时间戳两端不同 → 用 ClientOnly 兜底 -->
  <ClientOnly>
    <LiveClock />
    <template #fallback>加载中…</template>
  </ClientOnly>
</template>

水合优化：Nuxt 的进阶能力

大型应用全量水合很贵。Nuxt 提供了细粒度控制：

• Lazy Hydration（延迟水合）：让组件在"可见时 / 空闲时 / 交互时"才水合，而非首屏立刻全部激活，用 hydrate-on-visible 等指令。
• Server Components（.server.vue）：只在服务端渲染、不发送对应 JS 到客户端，适合纯展示内容，减小 bundle。
• Islands 架构：静态页面里只对"交互孤岛"水合。

07路由是怎么生成的：从文件到路由表

Nuxt 没有让你手写路由配置，而是扫描 app/pages/ 目录，按文件名约定生成 Vue Router 的路由表。这套规则要背熟。

三个关键组件

• <NuxtPage />：当前路由匹配到的页面渲染出口（相当于 Vue Router 的 <RouterView>，但带 Nuxt 增强）。通常放在 app.vue 或父布局里。
• <NuxtLayout />：渲染布局外壳。
• <NuxtLink />：路由跳转链接，自带预取（prefetch）——视口内的链接会提前加载目标页面的代码与数据，让点击近乎即时。

// app/app.vue —— 应用根的典型写法
<template>
  <NuxtLayout>      <!-- 选用 layouts/ 中的外壳 -->
    <NuxtPage />   <!-- 渲染当前路由页面 -->
  </NuxtLayout>
</template>

页面级元数据：definePageMeta

在页面组件里用 definePageMeta 声明该路由的元信息——指定布局、绑定中间件、设置过渡等。它是编译期宏，会被提取出来挂到路由表上。

<script setup>
definePageMeta({
  layout: 'admin',            // 用 layouts/admin.vue
  middleware: ['auth'],        // 进入前跑 auth 中间件
  keepalive: true
})
</script>

08四种渲染模式：Nuxt 的"杀手锏"是混合渲染

同一个 Nuxt 应用，不同路由可以用不同渲染策略——这叫 Hybrid Rendering（混合渲染），通过 routeRules 配置，是 Nuxt 区别于纯 SSR 框架的核心竞争力。

// nuxt.config.ts —— 一个应用里混用多种策略
export default defineNuxtConfig({
  routeRules: {
    '/':          { prerender: true },          // 首页：构建时静态生成
    '/blog/**':   { prerender: true },          // 博客：SSG
    '/admin/**':  { ssr: false },             // 后台：纯 SPA
    '/news/**':   { swr: 3600 },              // 新闻：缓存 1 小时
    '/api/**':    { cors: true }              // 接口：开 CORS
  }
})

09关键数据结构：Nuxt 运行时的"内存模型"

这一节是你问题清单里的重点。Nuxt 运行时有几个核心对象贯穿始终，理解它们的形状（shape）就理解了框架的内部状态。

① NuxtApp —— 每次请求/会话的"上下文容器"

NuxtApp 是 Nuxt 运行时的中枢。在服务端，每个请求都创建一个全新的 NuxtApp 实例（避免请求间数据污染）；在客户端，整个会话共享一个。它由插件、中间件、组合式函数共享，用 useNuxtApp() 获取。它的关键字段：

const nuxtApp = useNuxtApp()
nuxtApp.$myPlugin           // 访问插件注入的能力
nuxtApp.payload.data        // 当前 payload 数据
nuxtApp.ssrContext?.event   // 仅服务端：h3 请求事件

② payload —— 跨越服务端/客户端鸿沟的桥

这是整个数据流的物理载体。SSR 渲染完后，Nuxt 把这次渲染用到的数据序列化，内联进 HTML（一个 <script> 块）。浏览器加载后，客户端 NuxtApp 读取它来"复活"状态，从而避免重复请求。payload 的主要分区：

③ useState 的返回结构 —— SSR 友好的全局 ref

useState<T>(key, init) 返回一个 Ref<T>，但它和普通 ref 的本质区别是：它的值登记在 payload.state[key] 里，会随 SSR 一起传到客户端。这就是 Nuxt 里"跨组件 + 跨服务端/客户端"共享状态的标准方式。key 必须唯一且稳定（用作序列化索引）。

④ AsyncData 返回对象 —— 数据请求的标准形状

useAsyncData/useFetch 不直接返回数据，而是返回一个结构化对象，每个字段都是响应式的：

const {
  data,        // Ref<T>     —— 结果数据
  pending,     // Ref<boolean> —— 是否加载中（4.x 也有 status）
  status,      // Ref<'idle'|'pending'|'success'|'error'>
  error,       // Ref<Error|null> —— 错误
  refresh,     // () => Promise  —— 手动重新请求
  execute,     // 同 refresh，用于 lazy/immediate:false 时手动触发
  clear        // 清空 data/error 回到初始
} = await useAsyncData('key', () => $fetch('/api/x'))

这个对象形状要背下来——面试问"useFetch 返回什么"就是答这个。注意 data 是 Ref，模板里直接 {{ data }} 会自动解包，但 <script> 里要 data.value。

⑤ RuntimeConfig —— 配置的运行时结构

分两层：顶层是仅服务端可见的私有配置（API 密钥等），public 子对象是会暴露到客户端的配置。可被环境变量覆盖。

10配置对象体系：nuxt.config.ts 全景

nuxt.config.ts 是唯一的全局配置入口，用 defineNuxtConfig 包裹（提供类型）。它的字段按职责分组，理解分组就能快速定位任何配置。

export default defineNuxtConfig({
  // —— 渲染 / 路由策略 ——
  ssr: true,
  routeRules: { '/admin/**': { ssr: false } },

  // —— 运行时配置（私有 + 公开）——
  runtimeConfig: {
    apiSecret: '',                  // 仅服务端，由 NUXT_API_SECRET 覆盖
    public: { apiBase: '/api' }       // 客户端可读，NUXT_PUBLIC_API_BASE 覆盖
  },

  // —— 模块（生态扩展）——
  modules: ['@pinia/nuxt', '@nuxt/image', '@nuxtjs/i18n'],

  // —— 全局 head / SEO 默认 ——
  app: { head: { title: 'My App', meta: [{ name: 'description', content: '...' }] } },

  // —— 构建 / Vite / Nitro 透传 ——
  vite: { /* Vite 配置 */ },
  nitro: { preset: 'node-server' }, // 部署目标

  // —— 实验特性 & 兼容 ——
  experimental: { typedPages: true },
  css: ['~/assets/main.scss']
})

11数据流全链路：把所有东西串起来

现在把前面的零件接成一条完整的线。这是你问题清单里"数据流怎么串起来"的总答案——一次首屏请求里，数据从数据库走到用户屏幕，再无缝交给客户端，全程不重复请求。

串联这条线的三个机制，对应前面三节：

• key 去重（§12）：useAsyncData 用 key 作为 payload 索引。两端用同一 key，客户端才能找到服务端存的数据。Nuxt 4 的去重更智能。
• payload 序列化（§09）：数据通过 payload.data[key] 跨端传递，靠 devalue 序列化。
• $fetch 同构（§12）：服务端调 $fetch('/api/..') 不发真实 HTTP，而是 Nitro 内部直接调用 handler（更快、无网络开销）；客户端调它才发真实请求。

状态共享的数据流（另一条线）

除了"请求数据"，还有"组件间共享状态"这条流，主角是 useState：服务端设的状态写进 payload.state → 随 HTML 传输 → 客户端水合时从 payload 恢复 → 全应用任意组件 useState(sameKey) 拿到同一个响应式引用。这保证了"服务端设的登录态，客户端无缝接上"。

12useFetch / useAsyncData / $fetch：三者怎么选

数据获取是 Nuxt 面试必考。关键是讲清三个 API 的分工——它们不是替代关系，而是分层关系。

<script setup>
// ✅ 首屏数据：useFetch（自动去重、自动写 payload）
const { data: posts, pending, error, refresh } =
  await useFetch('/api/posts', {
    query: { page: 1 },
    // lazy: true —— 不阻塞导航，data 先为 null 后填充
    // server: false —— 只在客户端拉（跳过 SSR）
    transform: (res) => res.items,   // 入库前转换
    getCachedData: (key, app) => app.payload.data[key] // 自定义缓存
  })

async function addPost() {
  // ✅ 用户动作：直接 $fetch，再 refresh 列表
  await $fetch('/api/posts', { method: 'POST', body: { title: 'hi' } })
  await refresh()
}
</script>

常用选项速记

• lazy: true —— 不阻塞路由导航；页面先渲染，数据后到（配 pending 做骨架屏）。
• server: false —— 跳过 SSR，只客户端请求（适合非 SEO 的私密数据）。
• immediate: false —— 不自动请求，等你调 execute()。
• watch: [pageRef] —— 依赖变化时自动重新请求。
• key —— 手动指定去重 key（动态 URL 时重要）。
• transform / pick —— 减小存进 payload 的体积（性能优化点）。

13状态管理：useState vs Pinia，与跨端传递

Nuxt 里"全局状态"有两个层级，面试要能说清何时用哪个，以及它们如何安全跨越 SSR 边界。

useState —— 内置的 SSR 安全状态

轻量场景的首选。它解决的核心问题是：普通 ref 定义在模块顶层会在 SSR 时被多个请求共享，造成数据串台（用户 A 的数据泄漏给用户 B）。useState 把状态绑定到当前请求的 NuxtApp 实例，并通过 payload 传到客户端，既隔离又可水合。

// composables/useCounter.ts（自动导入）
export const useCounter = () =>
  useState<number>('counter', () => 0)  // key + 初始化工厂
// 任意组件调用都拿到同一个、且能从服务端恢复的 ref

Pinia —— 复杂状态的标准方案

当状态有复杂逻辑（多 action、getter、模块化、devtools 调试）时用 Pinia，通过 @pinia/nuxt 模块集成。它同样做了 SSR 处理：服务端 store 状态序列化进 payload，客户端自动恢复。选择标准：

跨端传递的本质（再强调一次）

两者都依赖同一原理：服务端状态 → 序列化进 payload → 内联 HTML → 客户端水合时反序列化恢复。所以放进全局状态的东西必须可序列化。这也解释了为什么不能把"函数""类实例"塞进 store 的 state。

14服务端 server/ 与 Nitro：Nuxt 的全栈半身

server/ 目录让 Nuxt 不只是前端框架。这里的代码只在服务端运行，永远不会进客户端 bundle，所以可以安全地连数据库、用密钥。

API 路由：文件即接口

// server/api/users/[id].ts → 接口 /api/users/:id
export default defineEventHandler(async (event) => {
  const id = getRouterParam(event, 'id')        // 路径参数
  const query = getQuery(event)                   // ?a=b
  const body = await readBody(event)             // POST body
  const config = useRuntimeConfig(event)        // 读私有密钥

  const user = await db.users.find(id)         // 安全：仅服务端
  if (!user) throw createError({ statusCode: 404, statusMessage: 'Not found' })
  return user   // 自动 JSON 序列化返回
})

关键约定

• 文件名后缀指定 HTTP 方法：user.get.ts / user.post.ts / user.delete.ts。
• server/api/ 下的文件挂在 /api/*；server/routes/ 下挂在根（无 /api 前缀，适合 webhook、sitemap.xml）。
• handler 用 defineEventHandler 包裹，参数 event 是 h3 的请求事件对象——所有请求/响应操作都围绕它（getQuery、readBody、setResponseStatus、setCookie…）。
• 抛错用 createError，能带状态码，前端 useFetch 的 error 会接到。

Nitro 的其他能力

• 存储抽象 useStorage：统一的 KV 接口，底层可挂内存、Redis、文件系统、云 KV——切换存储不改业务代码。
• 缓存 defineCachedEventHandler：给接口加缓存层，配 TTL。
• 定时任务 scheduledTasks、Nitro 插件（服务端生命周期钩子）。
• 部署 preset：nitro.preset 切换即换部署目标（node-server / vercel / cloudflare / static…），同一份 server 代码到处跑。

15真实项目长什么样：把概念落到工程

理论讲完，看一个贴近生产的"用户中心"功能怎么用 Nuxt 各部件协作，帮你把所有概念串成肌肉记忆。

需求：/users/:id 用户详情页，需 SEO、需登录、列表可分页

// app/pages/users/[id].vue
<script setup>
definePageMeta({ middleware: ['auth'] })   // ① 登录守卫

const route = useRoute()
const { data: user, pending, error } =
  await useFetch(`/api/users/${route.params.id}`)  // ② SSR 拉数据+去重

useHead({ title: () => user.value?.name })       // ③ 动态 SEO
</script>

<template>
  <div v-if="pending">骨架屏…</div>
  <UserCard v-else-if="user" :user="user" />  <!-- 自动导入的组件 -->
  <ErrorBlock v-else :error="error" />
</template>

这一个页面就用到了：约定路由、动态参数、路由中间件、自动导入组件、同构数据获取、payload 去重、动态 SEO、SSR——几乎是整篇文档的缩影。

16性能与生产优化清单

面试常问"你做过哪些 Nuxt 性能优化"。按"减少 JS / 加快数据 / 优化渲染 / 缓存"四类记。

减少客户端 JS

• Server Components（.server.vue）：纯展示内容不发 JS。
• Lazy Hydration：非首屏交互组件延迟到可见/空闲再水合。
• 动态导入组件：<LazyHeavyChart />（Lazy 前缀 = 用到才加载）。
• 用 transform/pick 裁剪 payload，减小内联数据体积。

加快数据

• SSR 内部 $fetch 走 internal call，本身就快；避免在 setup 里裸用 $fetch 造成双请求。
• lazy: true 让非关键数据不阻塞导航。
• Nitro defineCachedEventHandler 缓存昂贵接口。

优化渲染策略

• 静态页 prerender（SSG）走 CDN；半静态用 swr/ISR；只有真正动态的才纯 SSR。
• <NuxtLink> 视口预取，让翻页近乎即时。

资源与构建

• @nuxt/image 做图片自动优化（格式/尺寸/懒加载）。
• 路由级代码分割是默认的——每个页面单独 chunk。
• 用 nuxi analyze 看 bundle 体积找大块。

17面试高频题库（带标准答案）

把这些答出来，覆盖率基本到 90%。建议先盖住答案自测。

18速查总表（面试前 5 分钟扫一遍）

核心概念一句话

API 速记

"哪段代码在哪跑"对照