强军对决
106.2MB · 2026-03-22
Vite 在官网上给自己的定位是“下一代 Web 构建工具”。这个定义很准确,也很克制:Vite 主要解决的是本地开发体验和构建效率,而不是完整的服务端问题。
但真实世界里的前端应用从来不是孤立存在的。它们通常还需要 API、数据库、身份认证、实时通信,甚至服务端渲染。换句话说,前端项目最终仍然需要一个服务端。Vite 本身并不负责这部分能力,但它始终为生态预留了足够的扩展空间,允许其他工具自然地构建在它之上。这恰恰也是 Vite 设计上最迷人的地方:边界清晰,但扩展能力很强。
沿着 Vite 的生态继续往下看,你很容易注意到 Nitro。
尤雨溪在谈到 Nitro v3 时,也给出过一个非常直接的评价:
如果你用过 Nuxt,那么你大概率对 Nitro 不陌生,因为它正是 Nuxt 的服务端引擎。Nitro 最早诞生于 Nuxt 3,目标也很明确:提供一个与部署环境解耦的服务端运行层。
不过,Nitro 现在早已不只是 Nuxt 的内部组件。 随着能力逐步独立,它已经开始扮演更通用的角色:既可以作为元框架的底层基础设施,也可以单独拿来构建服务端应用。
上周,前端是个发布周,不仅 Vite 升级到8,还发布了 Vite+ 这样革命性的工具。但是,很多不知道的是,Nitro v3 Beta 也悄悄发布了,它不是一次简单的小修小补,而是对底层架构的一次重新梳理:API 更精简,对 Web 标准更友好,也更贴近新一代工具链。
这次 v3 更新,至少带来了几个非常明确的变化:
nitro,取代了旧的 nitropack。server.ts 完全掌控入口,并接入自己偏好的框架,例如 Elysia、h3 和 Hono。Request、Response、Headers 和 URL 等标准原语进行了全面重写,得到的是更简洁、也更容易跨平台迁移的服务端代码。所以,如果只把 Nitro 理解为“Nuxt 的一部分”,其实已经低估它了。至少从 v3 开始,Nitro 更像是在明确自己的新定位:它正在成为一个面向现代 JavaScript 全栈开发的轻量服务端框架。
如果你想直接从零开始,最快的方式就是使用 create-nitro-app:
pnpm dlx create-nitro-app
按照 CLI 提示完成初始化后,就可以直接启动开发服务器。
如果你已经有一个现成的 Vite 项目,也可以把 Nitro 直接接进去,为项目补齐 API 路由、服务端渲染等能力:
pnpm i nitro vite
先把 Nitro 插件加到 vite.config.ts 中:
import { defineConfig } from "vite";
import { nitro } from "nitro/vite";
export default defineConfig({
plugins: [nitro()],
});
然后创建一个 nitro.config.ts,告诉 Nitro 你的服务端代码放在哪里:
import { defineNitroConfig } from "nitro/config";
export default defineNitroConfig({
serverDir: "./server",
});
这里的 serverDir 表示服务端目录。也就是说,接下来放在 server/ 里的路由和相关代码,都会由 Nitro 接管。
例如,在 server/api/test.ts 中创建你的第一个 API 路由:
import { defineHandler } from "nitro";
export default defineHandler(() => {
return { message: "Hello Nitro!" };
});
Nitro 会根据文件路径自动生成路由,因此 server/api/test.ts 对应的访问地址就是 /api/test。
最后,启动开发服务器:
pnpm dev -- --open
现在,你就可以访问这个 API 路由了。
明天,我会继续讲讲我的开源项目,AI Elements Vue 和 Elevenlabs UI Vue 是怎么使用 Nitro 的,欢迎关注。
如果你觉得本文有用,一键三连(点赞、评论、转发),就是对我最大的支持。