Nuxt 项目总结

type

status

date

slug

summary

最近在使用 Nuxt 3 构建 SSR 项目的过程中，踩了不少坑，也积累了不少对比 Next.js 的体会，趁热记录一下，希望能帮到准备入坑 Nuxt 的朋友。

Nuxt 是基于 Vue 的服务端渲染框架，封装了很多配置，开发体验非常丝滑，官方还提供了 Server API、静态导出、多语言支持、模块生态、零配置等一整套完整方案，非常适合做中大型 Vue 项目。

如果你是 Vue 生态的开发者，Nuxt 是你构建 SSR 项目的第一选择。和 Next.js 一样，Nuxt 也支持 SSR / SSG / ISR / SPA 等渲染模式，还能通过模块机制快速集成 Tailwind、Auth、i18n 等功能。

Nuxt 会自动导入 composables、utils、plugins，如果你项目中多个地方定义了类似 useAuth 这样的函数，可能会莫名其妙出错，调试起来很痛苦。建议命名加上模块前缀，避免冲突。

和 Next.js 中 middleware 能返回 Response 不同，Nuxt 的中间件如果你用了 defineNuxtRouteMiddleware，它不支持 async + return Promise，必须用 navigateTo() 或抛出错误，否则会无效或者报错。

Nuxt 提供了 useFetch 用于服务端 + 客户端请求共享。但在使用时如果没有正确使用 server: false、或者在组件挂载前调用时机不对，会出现“hydration mismatch”问题。

特别是你用 useFetch 拉数据并用于 SSR 时，一定要注意 key 的唯一性以及是否启用缓存。

如果你在 plugin 中注入了某些工具函数或者实例，在使用 onMounted 的组件中使用它们，注意要等插件注入完成再用。建议封装成 useXXX() 再组合调用。

如果你在页面组件中监听某个 props 或参数的变化，不能只用 onMounted，需要额外使用 onBeforeRouteUpdate() 处理路由变化逻辑。

虽然 Nuxt 也提供 useHead 和 definePageMeta 来配置 meta 信息，但相比 Next.js 的 Head 和自定义 \_document.tsx 能力略弱，SEO 效果主要还得靠 SSR 输出内容的完整性。

数据获取方式：Next 的 getServerSideProps / getStaticProps 显式清晰，Nuxt 倾向用 useAsyncData 或 useFetch 更灵活但也更“魔法”一些。

部署：两者都支持 Vercel/Netlify 等平台，Nuxt 的 Nitro 适配能力更强，能部署到 Edge、Lambda、Cloudflare 等平台。

Nuxt 3 是一个优秀的 Vue SSR 框架，拥有强大的生态与现代化开发体验。虽然有些“魔法”机制容易踩坑，但一旦掌握之后能显著提升开发效率。

如果你是 Vue 用户，想构建一个 SEO 友好的 SSR 或混合应用，Nuxt 绝对值得一试。

当然，如果你更偏向显式逻辑、可控性高、TypeScript 一致性强，Next.js 仍是首选。

不同生态的选择本就没有绝对的优劣，关键在于团队习惯与项目定位。