
一份为专业开发者准备的 Nuxt 4 入门指南
第一部分:Nuxt 的优势:基础与起步
本部分旨在建立理解 Nuxt 价值定位所需的基础知识。它将从"为什么选择 Nuxt"过渡到"如何搭建项目",重点关注定义 Nuxt 4 体验的架构原则和工具。
第一节:为何选择 Nuxt?从 Vue 开发者到 Nuxt 架构师
对于专业的 Vue 开发者而言,将 Nuxt 视为一个全面的解决方案,而非仅仅一个库,是理解其价值的关键。Nuxt 旨在解决现代 Web 开发中遇到的复杂挑战。
超越 Vue.js:解决"元问题"
单独使用 Vue 构建大型应用时,开发者通常会面临一系列共同的挑战:手动配置 vue-router
、实现服务器端渲染 (SSR) 策略、管理状态水合 (hydration) 以防止前后端渲染不匹配,以及使用 Vite 等工具搭建一套完整的构建流程 1。
Nuxt 提供了一个集成化、有明确规范的系统,开箱即用地解决了这些问题,使开发者能够专注于功能开发,而非繁琐的样板代码 1。这种集成化的体验,正是 Nuxt 的核心价值所在。它将 Vue 的前端能力、Vite 的构建能力和 Nitro 的服务器能力无缝地编排在一起,其真正的"产品"是这种能够显著提升开发效率和降低认知负荷的顺滑开发体验。
Nuxt 方法论的关键优势:
- 默认开启服务器端渲染 (SSR): SSR 对首屏加载性能、用户体验 (UX) 和搜索引擎优化 (SEO) 具有深远影响。与客户端渲染的 Vue 应用需要等待 JavaScript 加载执行后才能显示内容不同,Nuxt 默认将完全渲染的 HTML 页面发送到浏览器,极大地缩短了"内容到达时间" 1。
- 基于文件的路由系统: Nuxt 约定
pages/
目录下的文件结构自动生成应用路由,这简化了项目组织,并消除了手动配置路由的需要 1。 - 自动导入 (Auto-Imports): 组件、组合式函数 (Composables) 和工具函数会被自动注册为全局可用,从而减少了重复的
import
语句,使代码库更加整洁 1。
核心哲学:约定优于配置
Nuxt 的设计哲学是"约定优于配置"。其"零配置"体验并非意味着功能缺失,而是提供了一套经过深思熟虑、可用于生产环境的默认设置,同时保留了在必要时进行覆盖和扩展的灵活性 3。这种方法与那些更灵活但需要大量配置的框架形成对比,有助于提升团队协作的一致性和项目的开发速度 10。
Nuxt 4:一次深思熟虑的演进
Nuxt 4 并非一次颠覆性的重写,而是一个以稳定性和优化开发体验为核心的迭代版本,它在 Nuxt 3 的坚实基础上进行了精炼 12。
Nuxt 4 的关键改进:
- 全新的
app/
目录结构: 这是最显著的视觉变化。此结构旨在提升文件监听器的性能,并更清晰地划分应用代码与项目配置文件 12。 - 更智能的数据获取: 优化了数据层的性能,例如默认采用浅层响应式和更高效的缓存策略。这些将在第二部分详细探讨 12。
- 更佳的 TypeScript 支持: 引入了基于项目的
tsconfig.json
文件分离机制,为应用代码、服务器代码等不同上下文提供了更精确的类型推断,改善了 IDE 的开发体验 12。
框架的设计演进往往是为了适应其底层工具的优势与局限。Nuxt 4 的目录结构调整正是对大型项目中性能瓶颈和开发体验摩擦的直接回应。在大型项目中,扁平化的目录结构会导致 Chokidar 等文件监听工具效率降低,进而拖慢热模块替换 (HMR) 和开发服务器的启动速度,最终影响开发体验。通过将应用核心代码隔离到 app/
目录中,Nuxt 缩小了需要被监听的文件范围,从而带来了更快的响应速度,尤其是在 Windows 系统上 12。这一架构转变体现了框架在成熟过程中对优化整个开发生命周期的专注。
第二节:项目初始化与工具链
本节将指导开发者完成创建 Nuxt 4 项目的完整流程,并熟悉开发过程中不可或缺的工具。
环境准备与先决条件
- Node.js 版本: 确保安装了 Node.js 的最新长期支持 (LTS) 版本,推荐使用偶数版本号,如 18 或 20 17。
- 代码编辑器: 强烈推荐使用 Visual Studio Code,并安装官方的 Vue Language Features (Volar) 扩展,以获得最佳的智能提示和类型检查体验 17。
- 代码注意事项: 对于 Windows 用户,建议使用 WSL (Windows Subsystem for Linux) 进行开发。这可以有效规避原生 Windows 文件系统可能导致的热模块替换 (HMR) 性能问题 17。
创建你的第一个 Nuxt 4 项目
使用 Nuxt 的命令行工具 nuxi
是官方推荐的脚手架方法,它能确保项目结构和配置的正确性 17。
代码片段:
Bash
perl
# 使用你偏好的包管理器
npm create nuxt@latest my-nuxt4-app
cd my-nuxt4-app
开发服务器与 Nuxt DevTools
- 通过运行
npm run dev
命令启动开发服务器。可以附加-- -o
或--open
标志使其在启动后自动在浏览器中打开项目 17。 - Nuxt DevTools 是一个集成在浏览器中的强大调试工具,对于理解和调试应用至关重要。它允许开发者检查组件、自动导入的函数、虚拟文件系统等,深入洞察框架的内部工作机制 3。
nuxi
命令行工具不仅是一个一次性的项目脚手架,它贯穿于整个开发工作流之中。开发者可以使用 nuxi add
命令来快速创建页面、组件、布局等,这不仅提升了效率,更重要的是,它强化了 Nuxt 的约定,确保新创建的文件遵循框架的最佳实践 20。将
nuxi
视为一个核心生产力工具,而非仅仅是一个安装器,有助于更好地融入 Nuxt 的开发生态。
第三节:理解 Nuxt 4 的目录结构
本节将详细介绍 Nuxt 4 的项目结构,阐明每个目录的职责,并特别强调不同配置文件之间的关键区别。
全新的 app/
目录:应用的核心
在 Nuxt 4 中,应用的核心代码默认存放在 app/
目录内 12。这一变更是向后兼容的;如果 Nuxt 检测到项目中存在旧的 Nuxt 3 结构(例如顶层的
pages/
目录),它仍然会正常工作 12。
核心子目录概览:
app/pages/
:用于基于文件的路由 8。app/components/
:用于存放可复用的 Vue 组件,支持自动导入 2。app/layouts/
:用于定义页面布局,如页眉和页脚 20。app/composables/
:用于存放自动导入的可复用 Vue 组合式函数 24。app/assets/
:用于存放需要经过构建工具处理的资源,如样式表、字体或图片 8。public/
:用于存放静态资源,这些资源会直接从项目根路径提供服务(例如favicon.ico
,robots.txt
)8。
server/
目录:通往全栈的大门
server/
目录是所有服务器端逻辑的所在地,由 Nitro 引擎驱动 1。此目录中的代码
仅 在服务器端运行。其子目录包括:api/
用于 API 路由,middleware/
用于服务器中间件,utils/
用于服务器端工具函数 26。
配置深度解析:nuxt.config.ts
vs. app.config.ts
澄清这两个主要配置文件的用途是理解 Nuxt 配置系统的关键,这也是新手常见的困惑点。
nuxt.config.ts
:这是项目的主配置文件 。它用于定义 Nuxt 模块、构建设置、服务器运行时配置(包括私有密钥),以及任何在构建时确定的配置 9。app.config.ts
:此文件用于定义那些在构建时确定且可以安全暴露给客户端的公共令牌 。它非常适合存放非敏感的应用级别配置,如主题变量、网站标题等。构建后,其值不能被环境变量覆盖 9。
表 1:配置文件职责划分
为了提供一个清晰的参考,下表总结了两个配置文件的核心职责,帮助开发者决定将配置项放在何处。
特性 | nuxt.config.ts |
app.config.ts |
---|---|---|
主要用途 | 构建时和服务器端配置 | 公共的、应用级别的配置 |
环境变量 | 可通过环境变量覆盖 (runtimeConfig ) |
构建后无法被环境变量覆盖 |
客户端访问 | 仅 runtimeConfig.public 部分暴露 |
完全暴露给客户端 |
典型内容 | 模块、构建选项、私有 API 密钥、head 默认值 |
主题设置、网站标题、功能开关 |
敏感性 | 可包含敏感/私有密钥 | 仅应包含公共、非敏感数据 |
第二部分:构建应用:视图、数据与状态
本部分将深入探讨核心的开发循环:创建用户界面、获取数据以填充界面,以及在服务器和客户端之间管理应用状态。
第四节:使用页面和布局构建视图
本节旨在教授开发者如何利用 Nuxt 强大而直观的路由和布局系统来构建应用的可视化层。
文件路由系统的实际应用
通过在 app/pages/
目录下添加 .vue
文件来创建页面是 Nuxt 的核心特性之一 7。
代码片段 (静态路由):
代码段
xml
// app/pages/about.vue
<template>
<h1>关于我们</h1>
</template>
代码片段 (动态路由):
使用 [param] 语法定义动态路由段。
代码段
bash
// app/pages/users/[id].vue
<template>
<h1>用户资料: {{ $route.params.id }}</h1>
</template>
代码片段 (嵌套路由):
通过文件夹结构和在父页面组件中使用 组件来创建嵌套路由 22。
代码段
javascript
// app/pages/settings.vue
<template>
<div>
<h2>设置</h2>
<nav>...</nav>
<NuxtPage /> </div>
</template>
// app/pages/settings/profile.vue
<template>
<h3>编辑你的个人资料</h3>
</template>
使用 useRoute
访问路由参数
useRoute()
组合式函数是符合 Composition API 范式的标准方式,用于在 <script setup>
中访问当前路由的信息 7。
代码片段与注意事项:
代码段
xml
// app/pages/users/[id].vue
<script setup lang="ts">
import { computed } from 'vue';
const route = useRoute();
const userId = computed(() => route.params.id);
// 注意事项:始终将路由参数视为可能不受信任的输入。
// 在使用它们之前(尤其是在 API 调用中)进行验证或清理。
</script>
<template>
<h1>用户资料: {{ userId }}</h1>
</template>
通过布局创建可复用的 UI
布局是包裹页面的组件,用于实现跨页面的通用 UI 结构,如页眉和页脚 23。
代码片段 (默认布局):
app/layouts/default.vue 文件会被自动用作默认布局。 组件至关重要,它标记了页面内容的注入点 20。
代码段
xml
// app/layouts/default.vue
<template>
<div>
<AppHeader />
<main>
<slot />
</main>
<AppFooter />
</div>
</template>
代码片段 (自定义布局及其应用):
创建一个具名布局(例如 app/layouts/admin.vue),并使用 definePageMeta 将其应用于特定页面 22。
代码段
xml
// app/pages/admin/dashboard.vue
<script setup lang="ts">
definePageMeta({
layout: 'admin',
middleware: 'auth' // 其他元数据示例
});
</script>
<template>
<h1>管理员仪表盘</h1>
</template>
文件路由和布局系统的结合构成了一种强大的架构模式,它促进了关注点的清晰分离。页面负责其特定的内容("是什么"),而布局则处理周围的通用结构("如何呈现")。这种解耦使得代码库的可维护性和可扩展性显著增强。definePageMeta
宏是连接特定页面与特定布局的桥梁 22。这意味着开发者可以通过修改单个布局文件来改变整个网站区域(例如"admin"区域)的外观,而无需触及任何单个页面文件。这体现了软件设计的核心原则之一:不要重复自己 (DRY)。
第五节:精通数据获取
本节旨在为 Nuxt 的数据获取机制提供一份权威指南,解释每种方法的细微差别以及如何在 SSR 上下文中高效地使用它们。
三位一体:useFetch
、useAsyncData
与 $fetch
本节将分解三种主要的数据获取方式,并阐明它们之间的关系。
$fetch
: 这是基础。一个强大的、同构的 fetch 工具(源自ofetch
),可在服务器和客户端两端工作。它非常适合在服务器路由中直接使用,或用于处理客户端事件(如表单提交)28。useAsyncData
: 这是核心的、支持 SSR 的组合式函数。它包装一个异步函数(通常内部使用$fetch
),处理服务器端执行,并将状态传输到客户端以防止"二次获取"。它需要一个唯一的键 (key) 来进行去重 29。useFetch
: 这是便利层。它是对useAsyncData
和$fetch
的封装,能根据 URL 和选项自动生成 key。在组件中从 API 端点获取数据时,这是最常用的选择 30。
SSR 友好的数据获取:Nuxt 如何防止二次获取
Nuxt 通过"水合" (hydration) 过程来解决二次获取问题:数据在服务器上获取,页面被渲染成 HTML,获取到的数据被序列化并嵌入到 HTML 载荷中。在客户端,Nuxt 读取这个载荷并"水合"应用状态,从而避免了重新请求相同的数据 29。
代码注意事项: 必须强调,在组件的 <script setup>
中直接使用 $fetch
而不通过 useAsyncData
或 useFetch
包装,将导致二次获取问题,因此应避免用于页面初始化数据的加载 28。
代码片段与最佳实践
代码片段 (基本的 useFetch
):
代码段
xml
<script setup lang="ts">
const { data: products, pending, error, refresh } = await useFetch('/api/products');
</script>
<template>
<div v-if="pending">加载中...</div>
<div v-else-if="error">错误: {{ error.message }}</div>
<ul v-else>
<li v-for="product in products" :key="product.id">{{ product.name }}</li>
</ul>
<button @click="refresh">刷新数据</button>
</template>
代码片段 (useAsyncData
与唯一键):
代码段
xml
<script setup lang="ts">
const route = useRoute();
const { data: post } = await useAsyncData(
`post-${route.params.slug}`, // 唯一键至关重要!
() => $fetch(`/api/posts/${route.params.slug}`)
);
</script>
代码注意事项: key
是最重要的参数。虽然 useFetch
会自动生成它,但对于 useAsyncData
或当 useFetch
的 URL 不够独特时,提供一个明确且唯一的 key
是必不可少的,以防止不同调用的数据相互覆盖 16。
Nuxt 4 的优化:浅层响应式
在 Nuxt 4 中,这些组合式函数返回的 data
ref 默认是一个 shallowRef
14。这是一项显著的性能优化,因为 Vue 无需在大型对象或数组内部进行深度的递归变更追踪。
代码注意事项: 在大多数情况下,这是理想的行为。如果确实需要深度响应性(例如,直接修改获取到的数据中的嵌套属性并期望 UI 更新),则必须通过 { deep: true }
选项明确选择加入 15。
表 2:数据获取组合式函数对比
为了帮助开发者根据不同场景选择正确的工具,下表清晰地列出了每种数据获取方法的用例和特性。
方法 | 主要用例 | 是否需要 Key? | 返回值 | 是否支持 SSR? |
---|---|---|---|---|
$fetch |
在服务器路由或客户端事件处理器中直接调用 API。 | 否 | Promise<data> |
否 (自身) |
useAsyncData |
为 SSR 包装任何异步逻辑,需要显式提供 key。 | 是 (手动) | { data, pending, error,... } |
是 |
useFetch |
在组件中从 API 端点获取数据,自动生成 key。 | 是 (自动) | { data, pending, error,... } |
是 |
第六节:通用上下文中的状态管理
本节旨在解释如何在 SSR 环境中管理跨组件共享的状态,重点介绍 Nuxt 的内置解决方案以及何时应采用更强大的工具。
useState
:简单、SSR 安全的状态共享
useState
是 Nuxt 为 SSR 友好的共享状态提供的解决方案。它本质上是一个 ref
,但其值能在从服务器端渲染到客户端水合的过程中得以保留 31。
它解决的根本问题是"水合不匹配"。如果一个状态在服务器上用一个随机或用户特定的值初始化,而在客户端又用一个不同的值重新初始化,那么 DOM 就会出现不匹配,从而导致错误 33。
useState
确保客户端以与服务器完全相同的状态开始,从而避免了这个问题。
代码片段与最佳实践
代码片段 (定义和使用共享状态):
最佳实践是将 useState 包装在一个组合式函数中,以实现类型安全和可复用性。
TypeScript
typescript
// app/composables/useCounter.ts
export const useCounter = () => useState<number>('counter', () => 0);
代码段
xml
// app/components/TheCounter.vue
<script setup lang="ts">
const counter = useCounter();
</script>
<template>
<div>
<p>计数器: {{ counter }}</p>
<button @click="counter++">+</button>
</div>
</template>
代码注意事项: 在通用应用中,切勿在文件的顶层作用域使用 ref
来定义状态。这会创建一个在服务器上跨所有用户请求共享的单例,从而导致数据泄露 31。此外,请确保存储在
useState
中的数据是可序列化的(不包含函数、类等)32。
扩展:何时以及为何集成 Pinia
useState
非常适合处理简单到中等复杂度的状态。对于复杂的全局状态管理,特别是当需要 actions、getters 以及 Vue DevTools 的时间旅行调试等高级功能时,官方推荐的解决方案是 Pinia 31。Nuxt 提供了专门的 Pinia 模块,可以自动处理复杂的 SSR 设置。
useState
和 useAsyncData
可以被看作是同一枚硬币的两面:它们都是用于实现从服务器到客户端的状态序列化和传输 的机制。useAsyncData
处理从外部源获取的数据的状态传输,而 useState
则处理应用内部生成的状态的传输。理解这一共同目标揭示了 Nuxt 的一个核心架构原则:管理服务器-客户端状态转换是框架的一等公民。这对于任何通用渲染框架来说都是一个至关重要的概念,以确保客户端 Vue 应用能够以生成服务器渲染 HTML 时所使用的完全相同的状态进行初始化,从而防止水合不匹配。
第三部分:借助 Nitro 释放全栈能力
本部分将介绍 Nuxt 的服务器引擎 Nitro,演示如何在不离开 Nu-xt 项目的情况下构建一个真正的全栈应用。
第七节:创建服务器端点
本节旨在教授开发者如何在他们的 Nuxt 应用中创建服务器端的 API 端点。
你的第一个 API:在 server/api/
中构建路由
server/api/
目录中的任何文件都会自动成为一个 API 端点。例如,server/api/hello.ts
会映射到 /api/hello
路由 26。
代码片段 (基本的 GET 端点):
TypeScript
javascript
// server/api/hello.ts
export default defineEventHandler((event) => {
return { message: 'Hello from the server!' };
});
处理请求、查询参数和请求体
通过文件命名约定来处理不同的 HTTP 方法(例如 submit.post.ts
)26。使用
getQuery
读取查询参数,使用 readBody
读取请求体 26。
代码片段 (带请求体解析的 POST 端点):
TypeScript
csharp
// server/api/users.post.ts
export default defineEventHandler(async (event) => {
const body = await readBody(event);
// 创建新用户的逻辑...
console.log('新用户:', body);
setResponseStatus(event, 201); // 设置 HTTP 状态码
return { success: true, user: body };
});
Nuxt 中 Nitro 引擎最强大的特性之一是同构 fetch 优化 。当在 SSR 过程中调用内部 API 路由时(例如 useFetch('/api/hello')
),Nuxt 不会发起一个实际的 HTTP 网络请求。相反,它会直接在进程内调用相应的事件处理函数 28。这种机制消除了网络延迟,带来了巨大的性能提升,这是前后端分离部署时无法实现的。因此,在 Nuxt 中将 API 与前端代码并置,不仅是为了方便,更是为了在服务器渲染期间获得切实的性能优势,这也是其全栈方案的一个关键卖点。
第八节:服务器中间件
本节将解释服务器中间件的角色,以及如何创建它来执行日志记录或身份验证检查等任务。
拦截请求
server/middleware/
目录中的文件会在每一个到达服务器的请求被处理之前运行,无论这个请求是针对 API 路由还是页面渲染 26。这使得它们成为处理日志记录、添加请求头或执行初始身份验证检查等横切关注点的理想场所。
代码片段与注意事项
代码片段 (日志中间件):
TypeScript
javascript
// server/middleware/logger.ts
export default defineEventHandler((event) => {
console.log(`[${event.method}] 新请求: ${getRequestURL(event).pathname}`);
});
代码注意事项: 服务器中间件不应该 返回一个值或结束响应。它的职责是修改 event
上下文或执行副作用。返回一个值会使请求短路,阻止它到达预期的处理器 26。
对于新手来说,服务器中间件 (server/middleware/
) 和路由中间件 (app/middleware/
) 之间的区别是一个常见的混淆点。服务器中间件在 Nitro/服务器层面操作原始的 HTTP 请求,它对所有请求生效,包括 API 调用和静态资源请求 26。而路由中间件则在 Vue/
vue-router
层面工作,在客户端或服务器端的页面导航之间运行,它不会对直接的 API 调用生效 7。澄清这一区别对于开发者选择正确的工具来执行身份验证等任务至关重要,因为复杂的身份验证场景通常需要两者结合使用。
第四部分:从开发到部署
最后一部分涵盖了生产级别的关注点,确保应用不仅功能完善,而且经过优化、可扩展,并为全球发布做好准备。
第九节:SEO 与元数据管理
本节旨在为开发者提供管理文档头部和实施强大 SEO 策略的工具。
为搜索引擎优化
Nuxt 的 SSR 基础为 SEO 提供了巨大优势 1。以下工具用于微调这一优势。
useHead
: 这是以编程方式管理head
标签的主要组合式函数。它是响应式的,可用于设置任何有效的head
元素 35。useSeoMeta
: 这是一个更高级别、类型安全的组合式函数,专门用于常见的 SEO 元标签(title
,description
,og:image
等)。它有助于避免常见拼写错误(例如name
vsproperty
),是推荐的 SEO 实现方式 36。
代码片段与注意事项
代码片段 (产品页面的动态 SEO 标签):
代码段
xml
<script setup lang="ts">
const { data: product } = await useFetch('/api/products/some-product');
useSeoMeta({
title: () => `${product.value.name} - 我的商店`,
description: () => product.value.description,
ogTitle: () => `${product.value.name} - 我的商店`,
ogDescription: () => product.value.description,
ogImage: () => product.value.imageUrl,
twitterCard: 'summary_large_image',
});
</script>
代码注意事项: 在处理用户生成的内容并将其用于元标签时,务必使用 useHeadSafe
来防止跨站脚本 (XSS) 攻击。它会对输入进行清理,确保只渲染安全的属性和值 38。
第十节:使用模块扩展 Nuxt
本节将介绍模块生态系统,它是扩展 Nuxt 功能和集成第三方服务的主要方式。
Nuxt 生态系统简介
模块是在构建时运行的函数,用于扩展 Nuxt 的核心功能。它们可以添加插件、组件、组合式函数、服务器路由,并能修改构建过程的几乎任何部分 39。Nuxt 拥有一个庞大的生态系统,包含了用于 UI 库、内容管理、身份验证等领域的官方和社区模块 3。
实践案例:安装和配置 @nuxt/ui
以下是一个添加模块的真实案例。
-
步骤 1:安装
Bash
bashnpm install @nuxt/ui
42
-
步骤 2:配置
将模块添加到 nuxt.config.ts 文件中。
TypeScript
arduino// nuxt.config.ts export default defineNuxtConfig({ modules: ['@nuxt/ui'] })
-
步骤 3:使用
现在,来自 UI 库的组件已经被自动导入,可以在任何 .vue 文件中直接使用,这展示了模块系统的强大和简洁。
代码段
arduino// app/pages/index.vue <template> <UButton label="点我" /> </template>
第十一节:部署策略
本节为将 Nuxt 4 应用部署到现代无服务器平台和传统服务器环境提供了清晰、可操作的步骤。
为生产环境构建
- 运行
npm run build
命令。 - 生成的
.output
目录是一个自包含的、可用于生产的产物。重要的是,部署时只需要这个目录 1。
部署到无服务器平台 (Vercel)
像 Vercel 这样的平台对 Nuxt/Nitro 提供了原生支持 43。
步骤:
- 将项目推送到 Git 仓库(如 GitHub, GitLab)。
- 在 Vercel 中导入该项目。
- Vercel 会自动检测到这是一个 Nuxt 项目,配置好构建设置并完成部署。整个过程基本上是"零配置"的 43。
部署到传统的 Node.js 服务器
由于 .output
目录是一个标准的 JavaScript 项目,它可以在任何 Node.js 环境中运行。
步骤:
- 在本地或 CI/CD 服务器上运行
npm run build
。 - 将整个
.output
目录复制到服务器。 - (如果需要)在
.output
目录内安装依赖项,尽管 Nitro 的目标是最小化依赖。 - 运行服务器入口文件:
node.output/server/index.mjs
1。
由 Nitro 生成的通用 .output
目录是 Nuxt 实现"随处部署"理念的关键。它将应用程序与托管环境解耦,这意味着开发者在构建应用时无需担心最终的部署目标,并且可以轻松更换托管服务商而无需更改代码库 1。这是 Nuxt 提供的一种强大的、避免供应商锁定的能力 43。
表 3:Nuxt 3 到 Nuxt 4 迁移要点
此表为熟悉 Nuxt 3 的开发者提供了一个快速参考,总结了升级时需要注意的最重要的变化。
功能领域 | Nuxt 4 的变化 | 需要采取的行动 / 关键考量 |
---|---|---|
目录结构 | 代码默认移至 app/ 目录。 |
可选迁移。可使用 codemod 移动文件。Nuxt 4 向后兼容。 15 |
数据获取 | useFetch /useAsyncData 默认返回 shallowRef 。 |
若需深度响应性,请使用 { deep: true } 。大多数应用无需更改。 13 |
数据获取 | data 和 error 的默认值从 null 变为 undefined 。 |
将 if (data.value === null) 的检查更新为 if (data.value === undefined) 或更简洁的 if (!data.value) 。 13 |
TypeScript | 生成多个针对特定上下文的 tsconfig.json 文件。 |
简化了根 tsconfig.json 。可能会暴露出之前被隐藏的类型错误。 12 |
组件命名 | 组件名称在整个应用和 DevTools 中保持一致的规范化。 | 提升了一致性,尤其对于动态组件和 <KeepAlive> 。 13 |