引言
作为前端开发者，几乎每天都要和包管理器打交道：安装依赖、执行脚本、拉取脚手架工具、运行临时命令……npm、yarn、pnpm 这些工具各有特色，而随着版本的演进，它们又衍生出了不少看起来相似却容易混淆的命令，比如 npx、pnpm dlx、pnpm create、yarn dlx、yarn exec 等。
不少同学第一次遇到时都会冒出疑问：
npx和npm到底有什么区别？pnpm dlx和pnpx是一样的吗？- 为什么
pnpm create能直接用来生成项目？ yarn为什么也有dlx了？
本文将带你 系统梳理这些命令的来龙去脉、用法差异和生态支持，并给出实际场景中的最佳实践，尽可能帮助你读完之后，能在日常开发中灵活选择，避免踩坑。
一、npm 与 npx
1. npm
npm 是 Node.js 默认的包管理工具。常见功能：
- 安装依赖：
npm install lodash - 运行脚本：
npm run dev - 发布包：
npm publish
它的本质是负责：
- 下载并管理
node_modules下的依赖包； - 通过
scripts字段统一命令入口； - 负责与 npm registry 交互。
2. npx
npx 是 npm 5.2+ 引入的工具，目标是 简化临时执行 npm 包的场景。
核心特性：
- 直接执行包命令，而不用手动安装。
- 优先使用本地依赖的可执行文件。
- 如果本地没有，会临时下载执行。
例子：
# 使用 create-react-app 创建项目（无需全局安装）
npx create-react-app my-app
以前要全局装：
npm install -g create-react-app
create-react-app my-app
而现在只需要 npx。执行完成后，临时安装的包会被清理。
总结：
npm负责管理依赖；npx更像一个 “包执行器”，负责临时运行依赖或远程包。
二、pnpm 系列命令
pnpm 近年来在前端社区快速流行，凭借 硬链接节省磁盘空间、快速安装 成为不少团队的首选。它除了 pnpm install、pnpm run 外，还对标了 npx，提供了更多的子命令。
1. pnpm dlx
相当于 npx，用来临时执行某个包。
例子：
pnpm dlx create-vite my-vite-app
与 npx 的不同点：
pnpm dlx会把临时下载的包缓存起来，下次执行同一个包时速度更快；- 但不会污染全局
node_modules。
2. pnpm create
pnpm create 是 pnpm dlx create-xxx 的语法糖。
比如：
pnpm create vite my-app
等价于：
pnpm dlx create-vite my-app
优势是更简洁，尤其在前端脚手架场景（vite、vue、react）里几乎成为推荐做法。
3. pnpm exec
与 npx 类似，但只会执行本地依赖里的命令，而不会自动下载。
例子：
pnpm exec eslint .
这会运行当前项目 node_modules/.bin/eslint。
与 dlx 的区别：
exec→ 运行本地依赖命令；dlx→ 运行远程包或未安装的命令。
4. pnpx？
历史上 pnpm 曾提供 pnpx 来对标 npx，但后来官方弃用，统一推荐用 pnpm dlx。
如果你看到旧项目里写了 pnpx，其实就是 pnpm dlx 的老版本。
三、yarn 系列命令
yarn 一度是 npm 的热门替代品，后来 yarn v1、yarn berry(v2+) 出现了差异。
在命令体系上，yarn 也逐渐引入了类似 npx 的能力。
1. yarn
常规操作和 npm 类似：
yarn add reactyarn run dev
2. yarn dlx
yarn dlx 出现在 yarn v2+，等价于 npx 或 pnpm dlx。
例子：
yarn dlx create-next-app my-next-app
3. yarn exec
与 pnpm exec 类似，主要执行本地依赖里的命令：
yarn exec eslint .
如果你需要临时执行远程包，则用 dlx。
四、对比总结
| 工具/命令 | 作用范围 | 是否临时下载 | 是否执行本地依赖优先 |
|---|---|---|---|
npm | 包管理器 | 否 | 是 |
npx | 执行器，支持远程包 | 是 | 是 |
pnpm exec | 执行本地依赖命令 | 否 | 是 |
pnpm dlx | 执行远程包，缓存加速 | 是 | 否 |
pnpm create | dlx create-* 的语法糖 | 是 | 否 |
pnpx | pnpm 老版本的 npx | 是 | 否 |
yarn | 包管理器 | 否 | 是 |
yarn exec | 执行本地依赖命令 | 否 | 是 |
yarn dlx | 执行远程包 | 是 | 否 |
一句话记忆：
- exec → 本地依赖
- dlx/npx → 远程包（脚手架、临时工具）
- create → 脚手架专属简写
五、最佳实践与踩坑指南
1. 什么时候用 npx / dlx？
- 新建项目（如
create-react-app,create-vite） - 临时用某个 CLI 工具（如
ts-node,http-server）
→ 不必污染全局环境。
2. 什么时候用 exec？
- 运行本地依赖的命令（如
eslint,jest,vite），确保与项目版本一致。 - 尤其在 CI/CD 环境里，用
pnpm exec/yarn exec更安全。
3. 全局安装是否过时？
大多数场景下，全局安装 CLI 已经不推荐，因为：
- 项目间版本可能冲突；
- 团队协作难以统一环境；
npx/dlx足够方便。
例外情况：
- 你频繁使用某个工具（如
pnpm本身、typescript编译器），全局安装反而能节省时间。
4. 关于缓存
npx每次都会重新拉包，可能导致速度慢。pnpm dlx和yarn dlx都会做缓存，下次执行更快。
5. 企业/团队最佳实践
在团队协作和项目管理中，选择合适的包管理器与命令规范尤为重要。以下是一些常见的实践建议：
- 统一采用 pnpm 作为包管理器：
由于pnpm的硬链接机制，能显著节省磁盘空间，安装速度也更快，适合大型团队和多项目并行的场景。 - 规定：本地工具用 exec，脚手架用 create/dlx：
pnpm exec eslint .→ 保证使用项目内的版本，避免 “我本地没问题，你那边挂了” 的情况；pnpm create vite→ 快速拉起新项目，避免全局安装。
- 配合 CI/CD，把命令写进 npm scripts，而不是直接调用：
例如：{ "scripts": { "lint": "pnpm exec eslint .", "dev": "pnpm exec vite" } }团队成员直接运行pnpm run lint即可，无需关注具体实现细节。 - 但需要注意：并不是所有团队都必须用同一种方案
- 如果团队已有大量基于 npm 的内部脚本，短期内迁移成本高，可以继续沿用 npm；
- 如果团队习惯 yarn berry 的 Plug’n’Play 模式，可以坚持使用 yarn，享受无
node_modules的环境； - 小团队或学习项目，直接用系统默认的
npm，避免增加工具学习成本； - 大型团队、多项目共存、磁盘/CI 安装速度敏感的场景，更推荐
pnpm。
换句话说：
👉 没有放之四海而皆准的最佳方案，工具是为人服务的。企业和团队应该根据 现有生态、人员习惯、CI/CD 环境和项目规模 进行权衡，选择最适合的方案，而不是一概而论。
六、技术生态与未来趋势
- npm 官方生态：体量最大，但发展速度相对保守。
- pnpm：社区和大厂（如 Vue、Vite、Nuxt）都在推荐，未来趋势明显。
- yarn berry：更灵活的 Plug’n’Play 模式，但学习成本较高。
生态支持：
- 大多数脚手架工具（
create-react-app,create-vite,create-next-app）已经同时支持 npm/yarn/pnpm。 - 一些新项目（比如 vitepress）甚至在文档里优先推荐
pnpm create。
趋势：
- 全局安装会越来越少用；
- “一条命令快速启动项目” 将依赖
dlx/create； exec将成为团队规范里保证一致性的关键。
七、总结
- npm vs npx：包管理 vs 包执行。
- pnpm exec vs dlx vs create：本地执行 vs 远程执行 vs 脚手架语法糖。
- yarn exec/dlx：与 pnpm 类似，只是命令前缀不同。
- 最佳实践：本地命令用 exec，脚手架用 dlx/create，全局安装仅保留少量必要工具。
- 趋势：pnpm 成为新主流，生态全面支持。
所以，今后当你要创建项目时，直接敲：
pnpm create vite my-app
当你要运行本地 eslint：
pnpm exec eslint .
就能稳妥、高效且不踩坑。
参考资料
文章评论