Nitro 服务端引擎概述

上一章我们写的接口，底层都由一个叫 Nitro 的引擎驱动。它最初是为 Nuxt 量身打造的，后来独立成了 UnJS 生态的一部分，别的框架也能用，甚至可以单独跑。对写应用的你来说，不需要钻进 Nitro 源码，但了解它的能力边界，能帮你少走很多弯路——尤其是「我的 Nuxt 应用能部署到哪」这种问题。

33-1

简单类比：Nuxt 负责「页面怎么渲染、组件怎么组织」，Nitro 负责「这些页面和接口在服务器上怎么跑、怎么对外提供服务」。它把你的服务端代码（API、中间件、服务端渲染逻辑）打包成一个独立的服务器程序。

Nitro 自带这些本事：

• 跨平台：能在 Node.js、浏览器（实验性的 service worker）、边缘网络等环境运行。
• 原生支持 Serverless（无服务器函数），开箱即用。
• 自动代码分割，按需异步加载。
• 内置开发服务器，带热更新。
• 支持「静态 + Serverless」的混合模式。

33-2

这是 Nitro 最硬核的能力。运行 nuxt build 后，Nitro 会把服务端产物输出到 .output 目录，里面是一个不依赖 node_modules 的 standalone 服务器。也就是说，部署时不用带着整个 Nuxt 源码和依赖，只把 .output 丢上去就能跑。

为什么这很重要？老版本 Nuxt 2 的服务器不是独立的，要靠 nuxt start 拉起 Nuxt 核心才能跑，脆弱又不适合 Serverless。Nitro 的 standalone 产物则干净利落，启动只要几毫秒，特别适合函数式和边缘环境。

33-3

「部署到哪」往往最让人头疼：Node 服务器、Vercel、Netlify、Cloudflare、Deno、Bun……每个平台的运行格式都不一样。Nitro 的解法是预设（presets）：你写同一套代码，构建时选一个预设，它就输出适配那个平台的产物。官方内置了 15+ 个预设，常见的包括：

• Cloudflare Workers（边缘）
• Netlify Functions
• Vercel
• Deno、Bun 等运行时

你通常不需要手写预设配置——部署平台（如 Vercel、Netlify）检测到 Nuxt 后会自动用对应预设。手动指定时，在 nuxt.config.ts 里通过 nitro 键（或更常见的命令行参数）选择即可。对初学者，记住「Nitro 让我一份代码多处部署」就够了，真要上线时对着目标平台的官方指南选预设。

33-4

Nitro 自带一组「服务端工具」（server utils），就是前面用过的那些 h3 助手（getQuery、readBody、setResponseStatus 等）。你还能在 server/utils/ 里加自己的工具函数，全服务端自动导入。

另一个容易被忽略的宝藏是 Nitro 存储层（storage）。它提供了一套跨平台的键值存储接口，底层可以挂不同「驱动」：本地文件、Redis、数据库等。比如你想在服务端缓存数据、记录访问次数，不用自己接数据库，用存储层就行。

export default defineNuxtConfig({
  nitro: {
    storage: {
      redis: {
        driver: 'redis',
        host: '127.0.0.1',
        port: 6379,
      },
    },
  },
})

export default defineEventHandler(async () => {
  const storage = useStorage('redis')

  const count = (await storage.getItem('visits')) || 0
  await storage.setItem('visits', Number(count) + 1)

  return { visits: count }
})

33-5

除了 API 和中间件，server/plugins/ 里的文件会被注册成 Nitro 插件，用来在服务器启动时做初始化、监听生命周期钩子：

export default defineNitroPlugin((nitroApp) => {
  console.log('Nitro 启动啦', nitroApp)
})

这适合放「全局只需做一次」的服务端逻辑，比如连数据库、预热缓存。

33-6

Nitro 有个叫 routeRules 的功能，能按路由定制渲染策略，非常强大。比如哪些页面构建时预渲染（利于 SEO）、哪些 API 缓存一小时、哪些旧地址要重定向：

export default defineNuxtConfig({
  routeRules: {
    // 构建时就生成好，利于 SEO
    '/': { prerender: true },
    // API 缓存 1 小时
    '/api/*': { cache: { maxAge: 60 * 60 } },
    // 旧页面重定向，避免 404
    '/old-page': {
      redirect: { to: '/new-page', statusCode: 302 },
    },
  },
})

其中 ssr、appMiddleware、noScripts 等是 Nuxt 专属的规则，用来改变页面渲染成 HTML 时的行为；appMiddleware、redirect、prerender 还会影响客户端行为。混合渲染让我们能在一套应用里，让首页静态化、让 dashboard 走 SSR、让接口走缓存，各取所需。

33-7

Nitro 是 Nuxt 服务端的「发动机」：它输出独立、跨平台、启动极快的服务器产物；用 presets 让一份代码部署到各种平台；用存储层提供跨平台键值存储；用 routeRules 实现混合渲染与缓存。理解这些，你就明白为什么 Nuxt 既能做纯静态站，又能做全栈应用，还能轻松上云。下一章我们聚焦 Nitro 里一个很实用的小角色——服务端中间件。

33-7 Nitro 的扩展能力

Nitro 不仅仅是一个服务端引擎，它还是一个可扩展的平台。你可以通过 Nitro 插件在请求处理的不同阶段注入自定义逻辑。比如在请求进来时做日志记录、在响应返回前添加安全头、在错误发生时上报监控。

Nitro 还支持自定义路由规则。通过 nuxt.config.ts 里的 nitro.routeRules，你可以为不同路径设置不同的缓存策略、重定向规则、CORS 配置等。这些都不需要写额外的代码，纯配置就能搞定。

另外，Nitro 的任务系统（Scheduled Tasks）允许你定义定时执行的任务，比如每天凌晨清理过期数据、每小时同步外部数据源。这个功能在 Nuxt 4 中得到了进一步增强，配合 nitro.storage 可以方便地存储任务执行状态。

33-8 Nitro 的存储系统

Nitro 内置了一套存储（Storage）系统，提供了一种统一的数据访问接口。无论你用文件系统、内存还是 Redis 作为后端存储，Nitro 的 API 都一样。这让应用在开发时用内存存储、上线后切换到持久化存储变得非常简单。

存储系统支持命名空间隔离。不同的数据放在不同的命名空间下，互不干扰。比如缓存数据放在 cache: 命名空间，会话数据放在 session: 命名空间。每个命名空间可以配置不同的存储后端和过期策略。

在开发环境下，Nitro 默认使用内存存储，重启后数据清空。生产环境下，推荐配置持久化存储（如 Redis 或文件系统），确保数据不会因进程重启而丢失。