---
title: "Nuxt CLI"
description: "Nuxt CLI 可在命令行中运行、构建和检查你的 Nuxt 应用"
canonical_url: "https://nuxt.zhcndoc.com/docs/4.x/api/commands/overview"
---
# Nuxt CLI

> Nuxt CLI 可在命令行中运行、构建和检查你的 Nuxt 应用

`@nuxt/cli` 就是 `nuxt` 命令：它会运行开发服务器、为生产环境构建你的应用、创建文件、管理模块并回答有关项目的问题。它是 `nuxt` 的依赖项，因此 Nuxt 项目已经包含它。

```bash [Terminal]
npx nuxt dev
```

该二进制文件安装为 `nuxt`，同时也会安装为 `nuxi`、`nuxi-ng` 和 `nuxt-cli`，以兼容较旧的配置。创建新项目是一个单独的包，[`create-nuxt`](https://nuxt.zhcndoc.com/docs/4.x/api/commands/init)，这样就可以在没有项目可供安装的情况下运行它。

`nuxi` 是第三个包：一个没有依赖项的独立 CLI，用于在项目外运行命令或全局安装。

## 要求

CLI 可在 Node v22.21+、v24.11+ 或 v26+ 上运行，并会在这些版本上原生导入 TypeScript 配置。不支持 Nuxt 2 和 `@nuxt/bridge`。

## 运行命令

在项目内，包管理器会运行项目所依赖的版本：

```bash [Terminal]
pnpm nuxt dev
npm exec nuxt dev
yarn nuxt dev
bun nuxt dev
```

在项目外或全局安装后，`npx nuxi` 会运行相同的命令。如果项目中安装了 `@nuxt/cli`，它会将每条命令交给项目中的 `@nuxt/cli`，因此实际运行的代码与其所在的 Nuxt 版本匹配，而不是与你机器上的版本匹配。当项目中没有 CLI、项目中的副本早于 v3.26，或项目中的副本不识别该命令时，它会回退到自身捆绑的命令，因此即使项目固定使用较旧的版本，也仍然可以获得较新的命令。

## 全局选项

`--cwd` 可以在命令名称之前或之后传递，这在 monorepo 中很有用：

```bash [Terminal]
npx nuxt --cwd apps/web dev
```

接受 `ROOTDIR` 位置参数的命令会将显式的 `--cwd` 视为对它的覆盖。任何命令上的 `--help` 都会打印其参数和选项，而 `--version` 会打印 CLI 版本。

## 拼写错误的命令和标志

无法识别的命令会与现有命令进行匹配，无法识别的标志会与该命令声明的标志进行匹配。在交互式终端中，系统会提供可供替代运行的更正内容；否则会将其报告为警告，因此拼写错误的标志不再看起来像是一个只是没有生效的标志。

## 项目命令

如果 CLI 没有提供某个命令，它会在项目中查找名为 `nuxt-<command>` 的二进制文件，因此依赖项可以添加自己的命令。这就是 [`nuxt build-module`](https://nuxt.zhcndoc.com/docs/4.x/api/commands/build-module) 的工作方式：它会运行由 `@nuxt/module-builder` 安装的 `nuxt-build-module` 二进制文件。

## Shell 补全

`nuxt complete <shell>` 会打印补全脚本，该功能由 [`@bomb.sh/tab`](https://github.com/bombshell-dev/tab) 提供支持。它可以补全命令、标志以及某些标志值：`nuxt dev` 的端口和主机、`nuxt build --preset` 的 Nitro 预设，以及日志级别。

::code-group
```bash [zsh]
npx nuxt complete zsh > "${fpath[1]}/_nuxt"
```

```bash [bash]
npx nuxt complete bash > /etc/bash_completion.d/nuxt
```

```bash [fish]
npx nuxt complete fish > ~/.config/fish/completions/nuxt.fish
```
::

同时也支持 `powershell`，而 `create-nuxt complete <shell>` 有自己的脚本，可以补全 starter 模板名称。

::note
如果安装了 [tab 的包管理器补全](https://github.com/bombshell-dev/tab?tab=readme-ov-file#package-manager-completions)，也可以通过包管理器使用补全（`pnpm nuxt <Tab>`）。
::

## 更新通知

CLI 每天会在后台检查是否存在更新版本的 Nuxt，如果有，则会在命令完成后显示简短提示，建议运行 [`nuxt upgrade`](https://nuxt.zhcndoc.com/docs/4.x/api/commands/upgrade)。`latest` dist-tag 会从 `.npmrc` 中配置的 registry 读取，并缓存在用户级别的 `.nuxtrc` 中。

对于预发布版本不会显示提示；同一 minor 版本内的补丁版本也不会显示提示，除非你至少落后了五个补丁版本。在 CI、StackBlitz 中，以及输出不是终端时，会跳过检查。

设置 `NUXT_IGNORE_UPDATE_CHECK=1` 或 `NO_UPDATE_NOTIFIER=1` 可跳过本次运行的检查，或者将 `updateCheck.enabled=false` 添加到用户级别的 `.nuxtrc` 中，以永久退出。

## 网络和代理

访问网络的命令（安装模块、搜索模块、下载模板、检查更新）会报告请求失败的原因，而不是原始错误，并建议最可能有效的重试方式。在会重新签署 TLS 流量的代理后面时，这意味着需要设置 `NODE_EXTRA_CA_CERTS`，并将其指向你所在组织的根证书。

只有在设置了 `NODE_USE_ENV_PROXY` 时，Node 才会读取代理环境变量；CLI 会将该设置继续传递给它生成的进程，因此由 `nuxt add` 启动的包管理器安装会使用与你相同的代理配置。

## 预发布版本

`main` 上的每次提交都会发布到 nightly channel：

```bash [Terminal]
npm install -D @nuxt/cli-nightly
npx @nuxt/cli-nightly dev
```

`create-nuxt-nightly` 会使用它创建项目，而 `npm create nuxt@latest -- --nightly` 会针对 Nuxt nightly channel 创建项目。

单个 pull request 的构建版本会由 [pkg.pr.new](https://pkg.pr.new) 发布，并从 pull request 本身链接过去，这是在正式发布前检查修复是否有效的最快方式。

---

- [来源](https://github.com/nuxt/cli)


## Sitemap

See the full [sitemap](https://nuxt.zhcndoc.com/sitemap.md) for all pages.