什么是 npx？
npx 是随 npm 提供的命令行执行器，用来运行本地或远程 npm 包提供的命令。未指定版本时，它优先使用项目已安装的工具；需要的包不在本地时，可以按需安装到 npm 缓存中再执行，无需提前全局安装。
本文以 npm 7 及之后的 npx 为主。这里的“免安装”指省去手动安装步骤，仍然可能发生下载和缓存安装；“环境隔离”指减少全局工具版本冲突，npx 不提供安全沙箱。
例如，npx serve 可以临时启动一个静态文件服务器，npx [email protected] "hello" 可以执行指定版本的演示工具。npx 获取工具的操作本身不会把它写入当前项目的 package.json，也不会把它全局安装。不过，被执行的脚手架或代码转换工具仍然可以创建和修改项目文件。
这里的“临时”不等于“每次都重新下载”。npm 会把临时获取的包放进自己的缓存，之后再次使用相同版本时可能直接复用缓存；缓存是否存在，不会改变它没有成为项目依赖这一事实。
npx 解决了全局安装的什么问题？
在 npx 普及之前，使用命令行工具常见的方式是全局安装：
npm install --global create-vite
全局安装可以使用，但会带来两个实际问题：
- 全局环境会持续堆积：不同项目用过的脚手架、格式化工具和构建工具都留在系统里，升级、卸载和排查来源的成本会增加。
- 同名工具难以共存：项目 A 可能需要旧版工具，项目 B 需要新版工具；在同一套 npm 全局安装目录中，同名包通常只有一个版本，升级容易影响其他项目。
npx 把“安装工具”和“执行工具”拆开：一次性的任务直接执行，项目长期依赖则写入 package.json。因此，官方脚手架常用 npx 或 npm create，因为用户不必先维护一套全局脚手架环境。
npx 执行命令时会发生什么？
一次典型的 npx <命令> 调用，可以按下面的顺序理解：
- npx 读取当前工作目录和项目依赖，寻找可执行文件。
- 找到本地命令时，直接执行项目中的版本。
- 本地没有匹配工具时，npx 根据包名或包规格从 npm 注册表获取它，并放到 npm 的缓存或临时执行环境中。
- 命令完成后，npx 不会把这次获取写入项目依赖清单；缓存可能保留，供后续调用复用。
图中文字勘误：“运行完成后清理”不适用于现代 npx 的缓存行为。执行进程会结束，但下载和安装到 npm 缓存中的文件通常会保留。
“本地优先”是团队协作中最重要的一步。项目已经在 devDependencies 中锁定了某个版本时，npx 通常会执行这个版本，而不是让每个人各自使用一份全局版本。
npm 和 npx 分别负责什么？
npm 负责包的安装、依赖管理、脚本运行和发布；npx 负责把包提供的命令执行起来。可以用下面的表格区分它们：
| 工具 | 主要职责 | 常见命令 | 是否改变项目依赖 |
|---|---|---|---|
npm install / npm uninstall | 安装或移除项目依赖 | npm install serve, npm uninstall serve | 默认会更新相关依赖声明与 lock 文件 |
npm run | 执行项目声明的脚本 | npm run build | 不负责安装包 |
npx | 执行 npm 包提供的命令 | npx vite, npx eslint@8 src/ | 默认不会写入项目依赖 |
一句话记忆：npm 把包带进项目，npx 把包提供的命令跑起来。 如果工具要成为项目构建流程的一部分，应该用 npm install --save-dev 安装并写入脚本，而不是每次依赖网络临时执行。
npx 是什么时候出现的？
npx 最初是一个独立发布的 npm 包，后来被 npm 集成。npm 5.2.0 起开始随 npm 提供；从 npm 7.0.0 起，npx 改为使用 npm exec 的实现，独立的 npx 包也被弃用。
因此，下面两条命令表达的是同一类操作：
npx cowsay "hello"
npm exec -- cowsay "hello"
npx 更短，适合文档和日常输入；npm exec 更明确地表达“执行 npm 包”，也更容易和 npm 的其他子命令放在一起理解。
npx 的查找顺序是什么？
对最常见的项目命令来说，可以先记住“本地项目优先，远程获取兜底”。如果需要精确控制行为，应使用明确的包名、版本号和参数，而不要依赖模糊的同名命令。
图示是简化模型，不能把“本地 → 系统 PATH → 下载”当成所有版本、所有参数写法下的固定规则。图中的“结束后不保留”也应改为“不会全局安装，缓存可能保留”。
例如项目安装了 Vite：
npm install --save-dev vite
npx vite --version
第二条命令会优先调用当前项目的 Vite。若当前项目没有这个包，npx 才会尝试根据包规格获取远程版本。更准确地说，包解析决定使用哪个包和版本，PATH 决定执行环境里能找到哪些命令，两者不能混为一谈。
未指定版本的包名可以匹配项目已有版本；明确写出 包名@具体版本 时，本地必须有对应名称和版本才能复用，否则会准备所请求的版本。--package 还允许把“提供命令的包”和“实际执行的命令名”分开写。系统 PATH 里的同名命令不能替代明确的版本约束。
包还需要在 package.json 的 bin 字段中声明命令入口。如果包没有命令入口，或多个入口无法唯一确定，直接写 npx 包名 会失败；npx 无法把任意函数库自动变成 CLI。
为什么官方脚手架推荐 npx 或 npm create？
脚手架的主要任务是生成一次项目骨架。对这种任务，长期把脚手架安装到全局通常没有必要，npx 可以把“取得脚手架”和“运行脚手架”合并成一条命令。
以 Vite 为例，官方常见写法是：
npm create vite@latest my-app
也可以直接运行对应的初始化包：
npx create-vite@latest my-app
npm create 是 npm init 的别名。对这里的非 scoped 包，npm create <name> 会映射到 create-<name>，再通过 npm exec 运行。因此两条 Vite 命令共享同一类执行机制，用户不需要额外维护一个全局的 create-vite。
图中的“用完即清”“用完不占地方”并不准确：服务可以停止，npm 缓存仍会占用磁盘空间。
这也是很多官方文档偏爱 npx 的原因：命令短、前置步骤少，且每个人都可以从同一条命令开始。对于需要长期参与构建的工具，脚手架创建项目后仍应把相关依赖写进项目自己的配置。
如果只想预览一个存放网页文件的目录，也可以进入该目录执行：
npx serve .
按终端显示的地址打开页面，完成后按 Ctrl+C 停止服务。它不会因为这一次预览成为全局包，但相关缓存可以留给下次使用。脚手架和静态服务器都仍然要求电脑具备工具所支持的 Node.js 版本。
如何用 npx 指定工具版本？
在包名后加 @版本号，就可以明确指定执行版本：
npx [email protected] "固定版本"
指定版本适合复现旧项目、验证升级影响或临时使用稳定版本。@latest 表示请求当前发布的最新标签，但“最新”会随时间变化；在 CI 或团队脚本中，更稳妥的做法是把工具装进项目并提交 lock 文件。
固定顶层包版本也不等于冻结整棵依赖树。若它的间接依赖使用版本范围，不同时间安装仍可能得到不同结果。严格复现应结合项目 lock 文件、npm ci 和一致的 Node.js 环境。
npx -p 怎样临时引入额外依赖？
-p 是 --package 的简写，用于先把指定包放进这次命令的执行环境，再运行后面的命令。例如临时使用 TypeScript 编译器：
npx -p typescript tsc --version
图中文字勘误：“自动清理、不留任何痕迹”不准确。这里临时提供的是命令执行环境，npm 缓存以及目标命令创建的文件都可能保留。
这个例子指定的包名是 typescript，实际命令名却是 tsc。--package 会把包提供的可执行文件加入本次进程的 PATH，也可以重复指定多个包。它不保证当前目录下任意 Node.js 脚本都能通过 require() 或 import 解析到这些缓存包；命令查找和模块解析是两套机制。
需要自动确认安装提示时，可以在包名或命令名前添加 --yes。确认来源后再用这个参数；反复使用的依赖仍应正常安装到项目中。
为什么 npx 会优先执行项目本地版本？
项目本地优先可以让团队共享同一套工具版本。假设项目的 package.json 中固定了 ESLint 8，那么：
npm install --save-dev --save-exact [email protected]
npx eslint src/
团队成员运行第二条命令时，通常会得到项目安装的 ESLint，而不是各自电脑上的全局版本。
这里使用旧版 ESLint 仅为说明固定版本；检查代码还需要与该版本兼容的 ESLint 配置，已有团队项目应遵循自己的工具链约定。
这并不意味着 npx 自动解决所有版本问题。真正保证可复现的是 package.json、lock 文件和一致的 Node.js 环境；npx 只是把项目声明的本地命令放到了执行入口上。
npx 下载的包会保存在哪里？
npx 临时获取的包不会自动写入当前项目的 package.json，通常也不会作为项目依赖出现在当前目录的 node_modules 中。npm 会使用自己的缓存目录保存下载内容和执行所需的安装文件，具体位置可以用下面的命令查看：
npm config get cache
图中“全局缓存”指项目之外、通常由当前用户共享的 npm 缓存，与 npm install -g 的全局安装目录不同。缓存命中可减少重复下载，但默认仍可能联网检查元数据；缓存存在也不保证一定可以离线运行。
缓存的作用是减少重复下载，不等于项目已经声明了这个依赖。需要清理缓存时可以使用 npm cache 相关命令，但日常不必为了“临时执行”频繁清空缓存。
npx 能直接运行 GitHub 仓库吗？
可以。npm 支持 GitHub 包规格，因此可以用仓库地址形式尝试运行命令，例如：
下面是语法示意，用户名和仓库名需要替换为真实、已核验的仓库：
npx github:用户名/仓库名
如果仓库没有正确声明可执行文件，或者需要额外参数，这条命令也可能无法直接工作。GitHub 仓库的分支内容还可能随时变化，所以它更适合测试和尝鲜，不适合未经审查就放进生产构建流程。
npx 用户名/仓库名 也是 GitHub 简写。需要固定代码时，可以用 github:用户名/仓库名#提交哈希 指定提交；仓库仍需有可安装的 package.json 和可识别的命令入口，安装过程还可能运行构建或生命周期脚本。
对工具作者而言，npx 缩短的是用户试用流程：正确配置 bin、发布包并写清运行环境后，用户可以复制一条命令开始体验。它不会免除作者对构建产物、依赖和安全性的维护责任。
npx 和 npm exec 有什么区别？
从 npm 7 起，npx 使用 npm exec 的实现。两者都能执行本地或按需获取的 npm 包，但参数解析存在差异：
| 写法 | 适合场景 | 说明 |
|---|---|---|
npx <包> <参数> | 日常命令、项目文档 | 更短，更容易复制 |
npm exec -- <包> <参数> | npm 脚本、需要强调执行语义的文档 | 与 npm 子命令体系一致 |
当参数可能被 npm 自己解析时，npm exec -- 中的 -- 可以明确分隔 npm 参数和目标命令参数。阅读官方文档时看到 npm exec，可以把它理解成 npx 的同类入口。
使用 npx 时，npx 自己的选项必须写在第一个位置参数之前，例如 npx --yes --package=typescript tsc --version；命令名后面的选项会交给目标工具。对应的 npm 写法是：
npm exec --yes --package=typescript -- tsc --version
还有一个易错点：-p 在 npx 中代表 --package，在 npm 中却代表 --parseable。改写命令时应使用完整的 --package。
使用 npx 时有哪些安全风险？
npx 的便利来自“获取后直接执行”，因此它也要求使用者确认来源。命令执行权限与当前终端用户相同，恶意包可以在安装脚本或运行阶段读取环境变量、文件和网络凭据。
执行陌生 npx 命令前，至少检查下面几项：
- 包名是否准确：仿冒包常用与热门包相似的拼写。
- 来源是否可信：优先查看 npm 页面、官方仓库、维护者和发布记录。
- 版本是否明确：脚本和 CI 尽量固定版本，不要让不可控的
latest进入关键流程。 - 命令是否需要高权限：不要在不理解内容时使用
sudo npx ...。 - 是否需要先查看代码：GitHub 仓库和冷门包应先阅读 README、
package.json和安装脚本。
--yes 只会跳过安装确认，不会让包变得可信。安全判断仍然要由使用者完成。
日常什么时候该用 npx？
下面三类场景最适合 npx：
图中“即用即删”和“环境隔离更安全”需要修正：缓存通常会保留，减少全局版本冲突也不代表运行在安全沙箱中。固定顶层版本只能控制一部分可复现条件。
| 场景 | 示例 | 为什么适合 |
|---|---|---|
| 一次性运行工具 | npx serve | 不必为了短期任务安装全局包 |
| 使用项目本地工具 | 已安装 Prettier 时运行 npx prettier . --check | 使用项目工具检查格式，无需全局安装 |
| 指定工具版本做验证 | npx [email protected] "hello" | 无需修改依赖声明即可执行指定版本 |
如果工具会被启动、测试、构建流程反复调用，就应该安装到项目的 dependencies 或 devDependencies，再通过 npm run 或项目脚本执行。npx 适合“现在用一下”；项目依赖适合“以后每次都要用”。
常见问题
npx 需要单独安装吗？
通常不需要。安装 Node.js 后会获得 npm，较新的 npm 会同时提供 npx 命令。可以用 node --version、npm --version 和 npx --version 检查当前环境。
npx 会把包安装到项目里吗？
临时获取的包默认不会写入 package.json，也不会作为项目依赖记录在 lock 文件中。它可能被 npm 放进全局缓存，以便后续调用复用。项目长期需要的包仍应使用 npm install 安装。
npx 和全局安装有什么区别？
全局安装把工具放进系统级环境，适合确实要在多个项目间长期使用的命令；npx 按次执行，优先使用项目本地版本，适合脚手架、一次性任务和版本隔离。
npx create-vite 和 npm create vite 一样吗？
它们都可以运行 Vite 的项目初始化器。npm create vite@latest 是 npm 提供的初始化器入口，会寻找并执行 create-vite；npx create-vite@latest 则直接写出要执行的包名。具体可用选项以对应版本的官方文档为准。
为什么 npx 执行时会询问是否安装？
当本地找不到目标包、需要从注册表获取时，npm 可能要求确认，以避免误执行拼写错误或陌生包。确认来源后，可以使用 --yes 自动接受，但自动确认不应替代安全检查。
总结：npx 到底是什么？
npx 是 npm 提供的命令执行器。它优先运行项目本地已经安装的工具，也能按需获取指定包和版本；临时获取的内容不会自动成为项目依赖，npm 缓存则可能保留下载结果。
官方脚手架推荐 npx 或 npm create，是因为创建项目通常是一次性动作：用户复制一条命令就能得到脚手架，不必先安装全局包。记住这三个判断就够了：一次性工具用 npx，项目固定依赖用 npm install，陌生命令先确认来源。
参考资料与延伸阅读
- npm 官方：npx：本地匹配、缓存安装、命令入口推断和参数规则。
- npm 官方：npm exec：执行环境、缓存选项，以及 npm 7 起的兼容性变化。
- npm 官方：npm init：初始化器如何映射到
create-*并通过 npm exec 执行。 - Vite 官方：开始使用：
npm create vite@latest的用法和运行环境要求。 - 本站：什么是 npm？：理解依赖声明、lock 文件与项目安装。