如果你现在打开终端输入npm -v和npx -v大概率两个命令都能正常输出版本号。但我在现实里见过太多人包括一些写了好几年业务代码的前端都说不清npx到底是干嘛的、跟npm有什么区别。这俩其实压根就不是一个维度的东西。今天这篇就把它们彻底拆开讲明白各自的分工、核心使用场景顺便把安装环境时最容易踩的坑一并捋一遍。1. 先搞清楚npm 和 npx 到底各管什么1.1 一句话版本npm 是包管理器npx 是包执行器npm全称 Node Package Manager是随 Node.js 一起安装的包管理工具。它的核心职责是管理依赖——安装install、卸载uninstall、更新update、发布publish包。你可以把它理解成你项目里的“仓库管理员”你告诉它需要什么货它把货搬到仓库node_modules里登记在台账package.json上还能帮你整理货架。重点关注的是“装了什么、版本是多少、依赖关系是否完整”。npx从 npm 5.2.0 版本开始内置它设计的初衷和核心职责是执行包。它关注的不是“把包装到哪”而是“这个包怎么跑起来”。比如你想临时用一下某个工具包又不想永久装进项目里污染依赖列表这时候npx正好派上用场。我用一个特别直白的类比来说明npm install像是在你家楼下超市买菜买米囤进冰箱东西是你的随时可以做菜但占地方囤多了冰箱会乱。npx更像是直接打电话叫厨师上门做菜做完就走不占用你家冰箱也不产生厨余垃圾。这个类比其实非常准确能解释后面要讲的几乎所有关键行为差异。1.2 为什么有了 npm 还需要 npx这是很多人心里的第一反应。明明我可以用npm install -g全局安装再直接用命令执行为什么还要多一个npx核心原因有两个避免全局环境污染和解决版本冲突。先说全局环境污染。npm install -g会往你的系统全局目录里塞可执行文件时间一长你根本记不清自己装过什么升级 Node.js 版本后还可能因为全局包的兼容性报错。更麻烦的是如果两个项目需要的工具版本不同比如项目 A 要 Vue CLI 4项目 B 要 Vue CLI 5全局安装只能保留一个版本另一个项目必然受影响。再说版本冲突。很多工具包会以项目依赖的方式装在当前项目的node_modules/.bin目录下但直接调用它你得写一长串路径比如./node_modules/.bin/webpack --version既难看又容易写错。npx做的事情就是把这层麻烦抹平了如果当前项目里已经装了某个包npx 包名会直接使用项目本地的版本如果本地没装它会临时下载一个到缓存里执行用完自动清理不在你的项目里留任何痕迹。所以从使用体验上说npx比npm更接近“用完即走”的轻量哲学。2. 从三个经典场景看清 npx 的核心价值2.1 场景一临时使用一次性工具我举一个最常见的例子npx create-react-app my-app。你新建 React 项目的时候根本不需要提前全局安装 create-react-app一行npx命令它会自己拉取最新版脚手架然后执行。再比如你想快速在当前目录起一个静态服务器用npx serve就能做到。如果是以前你得先npm install -g serve然后才能敲serve。现在npx serve一行搞定用完了还不占用任何全局目录。这种方式特别适合那种“一年也用不了几次”的长尾工具比如npx kill-port 3000杀掉占用 3000 端口的进程、npx npm-check-updates检查依赖更新、npx json2tsJSON 转 TypeScript 类型定义。我在实际项目中npx有几个非常高频的用法值得分享npx playwright install chromiumPlaywright 的浏览器安装命令我每次在 CI 环境或者新机器上跑自动化测试都会用它一次性装好浏览器内核既不污染全局环境又能在项目里锁定 Playwright 的版本。我以前在团队里见过有人在全局装了一套 Playwright然后项目里又装了另一套版本结果跑测试的时候浏览器内核和 API 版本对不上白白排查了半天。用npx配合项目本地版本就不会出这种岔子。npx eslint src/只用在当前项目的 ESLint 配置做检查不会因为全局 ESLint 版本太老而导致检查规则不一致。npx tsc --noEmit临时做 TypeScript 类型检查特别适合在不想跑一遍完整构建、只想快速确认类型正确性的场景。2.2 场景二精确控制工具的版本这是npx在工程化流程里价值最高的地方也是我极力推荐你建立的一个习惯。假设你的项目里已经安装了npm-check-updates的某个版本但你想试试新版本的命令行为是否一致又不想把项目里的依赖升级这时候可以这样执行npx --package npm-check-updates ncu--package参数可以让你指定一个临时包然后执行它的可执行命令。更精确一点的写法是直接锁版本npx --package typescript5.4.0 tsc --version这样你可以在不修改项目 package.json 的前提下临时用 5.4.0 版本的 TypeScript 编译一下看看会不会出新错误。这在排查“升级后构建失败”这类问题的时候非常高效省去了一来一回改版本、重装依赖的重复动作。这里额外提一个冷门但特别实用的命令npx -p node18 node -v。它可以用指定版本的 Node.js 去运行命令原理是 npx 会把 node18 这个 npm 包装进临时路径然后执行里面的 node 二进制。我遇到过一些老项目只能跑在 Node 14 上新项目需要 Node 20经常需要切换版本。虽然 nvm 能解决这个问题但在不想切换全局 Node 版本、只想临时用另一个版本跑一个脚本的时候npx -p node16 node script.js这种写法特别省事。2.3 场景三直接执行 GitHub 仓库代码npx还支持直接解析仓库地址。你如果看到别人的项目里写了一些很有意思的命令行工具并且仓库里配置好了对应的bin字段你可以直接执行npx github:username/repo当然这个做法有一定的安全隐患一般只建议在完全信任源码的情况下用但它确实让体验变得极其顺滑。结合前面说的临时下载执行机制npx在某种意义上就等于一个“免安装的命令行工具集市”。不过需要提醒的是在线执行远程代码本身是个双刃剑。如果你对仓库不熟悉千万不要轻易执行陌生人的 GitHub 仓库。这跟从 npm registry 安装一个知名包不是一个风险等级远程仓库的代码你大概率没有审阅过。我在团队内部一直强调这种用法只限于自己维护的仓库或者完全信任的开源项目。2.4 核心伪装npx 和 npm 的执行逻辑差异为了让你彻底理解这两个命令的执行差异用一个小实验来演示。我创建一个空目录打开终端mkdir npx-test cd npx-test npx cowsay hello如果之前没有全局装过 cowsaynpx 会立刻提示“Need to install the following packages: cowsayx.x.x. Ok to proceed? (y)”。输入 y它下载、执行、打印出牛说话的图案完事之后你在项目里看 node_modules不存在 cowsay。全局 npm root -g 里也不存在 cowsay。这就是 npx 的核心机制——临时安装、立刻执行、自动回收。它实际上会把这个包装在一个临时目录里执行完之后缓存在 npm 的_npx目录。下次再执行同一个包如果缓存还在且版本没变就秒起如果版本要求变了它会拉新版本。而npm没有任何“执行包”的职责它只负责“把包装好”。你让npm直接运行一个包的命令比如npm cowsay hello它只会站在那告诉你这不是一个合法命令。因为npm压根就没打算帮你执行任何东西它只管安装、删除、解析依赖。这里我可以给出一张非常清晰的对比表方便你一眼看懂二者定位差异对比维度npmnpx全称定位包管理器管理依赖包执行器运行命令核心职责安装、卸载、更新、发布依赖包临时安装并执行某个包的命令依赖落盘位置项目 node_modules 或全局目录临时缓存目录_npx是否污染项目依赖会写入 package.json不会不修改 package.json版本锁定能力通过 package-lock.json 锁依赖树通过--package参数临时锁执行版本典型使用时机项目依赖安装、依赖更新、发布包运行脚手架、执行一次性工具、版本对比首次执行前要做的准备初始化 package.json不需要直接跑2.5 npx 的查找优先级逻辑npx 在执行一个包名的时候查找顺序也是很多开发者踩坑的地方。搞清楚这个顺序能避免不少莫名其妙的报错。npx 会依次做这些查找检查当前项目的node_modules/.bin里有没有对应的可执行文件。有就直接用不管这个包是直接依赖还是间接依赖。检查全局安装的包通过npm root -g查看。如果全局有就执行全局版本。如果以上都没有从 npm registry 拉取这个包的最新版到临时缓存然后执行。这个逻辑带来的一个实际问题是如果你的项目 node_modules 里已经有一个老版本的包但你想通过 npx 用新版本直接npx 包名可能仍然用的是项目里那个老版本。这时候需要加--force或者用--package参数指定临时包来绕过本地优先级。比如你项目里装了 typescript 4.x但你想临时看一下 5.x 对.d.ts的生成差异npx --package typescript5.4.2 tsc --version这个命令会把 typescript 5.4.2 作为临时包下载然后执行其中自带的 tsc从而绕开本地 4.x 的干扰。3. 实操配置把 npm 和 npx 的安装环境调到最优前面都是概念和用法层面的内容接下来这部分我会把 Node.js 环境、npm 镜像源、npx 使用时常见的配置问题一次性整理清楚。热搜词里反复出现“npm 国内源”、“npm 镜像源”、“npm 环境变量 PATH 配置”以及“npm.ps1 禁止运行脚本”这几类问题说明它们真的太常遇到也几乎成了每个前端新手绕不过去的坎。安装和配置环境的时候这块踩坑率极高我按类型把它们全部展开讲一下。3.1 镜像源配置国内开发者的第一步刚需在国内默认的 npm 官方源是https://registry.npmjs.org/访问速度不稳定尤其是在下载大包的时候经常卡住。我相信你肯定遇到过npm install执行到一半进度条卡着不动然后超时报错的情况多半就是网络问题。解决方式很简单切换成国内镜像源。目前最常用的镜像是淘宝镜像它同步频率高、稳定性好而且不只是 npm registrynpx里的--package临时包下载也一样能走这个镜像。镜像源的配置有三种做法方式一命令行临时指定适合一次性npm install --registryhttps://registry.npmmirror.com这个方法适合偶尔用一次每次都要敲一遍比较繁琐。方式二写入配置文件推荐npm config set registry https://registry.npmmirror.com执行完之后可以验证一下是否生效npm config get registry如果输出https://registry.npmmirror.com/说明已经生效。这里我明确一个关键点改了 registry 之后npm 和 npx 的临时包下载都会走这个源。因为 npx 本质上是调用 npm 的下载机制所以镜像源配置对 npx 同样生效。方式三使用 nrm 管理多源nrm是一个专门用来切换 registry 的工具装一次全局就能来回切官方源、淘宝源、腾讯源等。如果你经常需要在多个源之间切换比如需要发布 npm 包时必须用官方源这个工具很实用npm install -g nrm nrm ls # 列出所有源 nrm use taobao # 切换到淘宝源 nrm use npm # 切回官方源注意当你需要发布 npm 包的时候一定要保证当前 registry 是官方源否则npm publish会报错。网上有很多人忘了切回官方源结果 publish 时报 403 或者 unrecognized registry排查半天才发现是源的问题。3.2 npm 环境变量 PATH 配置装了 Node.js 但命令找不到热搜词里“npm 不是内部或外部命令”、“npm 无法将‘npm’项识别为 cmdlet”这类问题归根结底就是 PATH 环境变量没有配置正确。Node.js 安装完成后npm 的可执行文件默认在 Node.js 安装目录下。Windows 系统一般安装在C:\Program Files\nodejs\macOS 通常在/usr/local/bin/或通过 nvm 管理Linux 下也类似。如果是 Windows 系统检查 PATH 的方法右键“此电脑”选择“属性”然后进“高级系统设置”。点击“环境变量”在“系统变量”里找到Path。确认里面包含C:\Program Files\nodejs\这个路径。如果不存在点击“新建”添加进去注意不要覆盖原有路径。配置完成后一定要重新打开终端窗口否则环境变量不会刷新。然后运行node -v npm -v npx -v这三条命令如果都能正常输出说明环境变量没问题。我遇到过很多次这种情况明明刚才npm install还能用过一会儿重启电脑或者换了终端npm命令就找不到了。这种时候十有八九是环境变量里被其他软件改动了。还有一种情况是路径里有多个 Node.js 版本共存比如用 nvm-windows 管理版本版本切换后 PATH 被重置了重新走一遍配置流程就行。3.3 Windows 上执行 npm 报“禁止运行脚本”的完整解法这个报错在热搜词里出现了至少三次基本是 Windows 用户的标配问题npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本这个报错的成因和 Node.js 本身没有关系它纯粹是PowerShell 的执行策略Execution Policy阻止了.ps1脚本运行导致的。npm 的 Windows 版不仅提供.cmd批处理文件还附带一个 PowerShell 脚本npm.ps1。当你使用 PowerShell 终端运行npm命令时就触发了这个限制。解决办法有几种按推荐程度排序第一种对当前用户开放远程签名执行权限推荐影响范围最小打开 PowerShell执行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserRemoteSigned的含义是本地创建的脚本可以运行从互联网下载的脚本必须经过签名才能运行。这既解决了 npm 的问题又不会把安全防护完全关闭是目前微软官方推荐的做法。执行完再输入npm -v就不会报错了。第二种在某个终端会话内临时放开适用一次性操作Set-ExecutionPolicy -Scope Process -ExecutionPolicy BypassProcess作用域只对当前 PowerShell 窗口有效关闭窗口后自动恢复适合不想修改系统设置的场景。第三种直接用 cmd 替代 PowerShell在地址栏输入cmd然后回车或者直接在资源管理器路径栏打开命令行窗口用 cmd 跑 npm 基本不受 PowerShell 执行策略影响。这对某些企业安全策略非常严格的电脑来说是一个应急方案。提示如果你在公司电脑上碰到这个报错先不要急着改执行策略有些公司域策略GPO会强制覆盖Set-ExecutionPolicy的设置。这时候最稳妥的做法是用 cmd 终端或者在 VS Code 里把默认终端切换到“命令提示符”。3.4 npx 在国内环境下有时会卡住的网络排查npx下载临时包也会走 npm 的 registry 逻辑所以如果你在npx create-react-app之类命令执行时卡住大概率还是网络问题。检查方向先看当前 registry 是不是淘宝镜像源npm config get registry。如果已经切到镜像源还是卡可以尝试清掉 npx 的缓存目录。Windows 在C:\Users\用户名\AppData\Local\npm-cache\_npxmacOS 在~/.npm/_npx。把它删掉再重新执行。终极办法把临时包下载解包时间拉长通过npm config set fetch-retries 5和npm config set fetch-timeout 600000增大超时时间。这种问题通常和公司网络代理有关尤其是企业内网环境需要走代理访问外网时。如果你所在网络需要 HTTP 代理才能访问外网还要给 npm 配置代理npm config set proxy http://你的代理地址:端口 npm config set https-proxy http://你的代理地址:端口有些公司代理还需要认证就把用户名密码拼进代理地址里格式是http://用户名:密码代理地址:端口。不过要注意尽量只在需要的时候设置代理并且用完后及时清理避免干扰后续开发。热词里还有一个很有意思的“npm 代理配置用户密码npm 淘宝安装最新代理”。这里我多说一句不要轻易相信网上流传的那种需要用户名密码的“代理源”绝大多数情况下你没那个账号。如果你在内网优先找运维同事要公司内部的 npm 镜像源地址自己配一下就行比盲目用外网代理靠谱得多。4. 高频报错排查与施工现场记录4.1 EPERM 权限问题报错示例npm error code EPERM npm error syscall unlink这个报错在 Windows 上极其常见。本质原因是npm 要删除或修改某个文件但系统权限不够或者这个文件正被其它进程占用。我遇到过的实际场景开发者用 VS Code 开着终端同时跑着一个正在监听文件变化的开发服务器比如npm run dev然后这时候执行npm install重新安装某个依赖大概率会碰到 EPERM。因为被占用文件无法删除。解决办法关闭所有编辑器、终端窗口、Node 进程可以打开任务管理器找 node.exe 结束。直接删除node_modules目录再重新安装。Windows 上如果删除时提示文件被占用重启电脑最省心。以管理员身份运行终端执行npm install很多 EPERM 问题迎刃而解。如果你是用npm install -g anthropic-ai/claude-code这类全局安装时遇到 EPERM多半是全局目录需要管理员权限。在 Windows 上npm 的全局目录如果刚好在C:\Program Files\nodejs\下普通用户没有写入权限就得用管理员终端安装而不是正常用户终端。4.2 内网离线环境的 node_modules 依赖带下划线问题这个案例是热搜词里一个程序员提到的“内网开发解压 node_modules发现里面依赖的名称都带_然后 npm run dev 报错”。我解释一下是怎么回事。npm 在安装依赖时如果两个包的依赖树有嵌套冲突而且包名无法同时放进一个扁平的node_modules目录npm 会在目录名外面加些特殊标记或者使用下划线开头/结尾命名的目录。常见的命名方式类似于_dependency-name或dependency-nameversion看起来像是“重命名”了实际上这是 npm 在非常规环境下产生的依赖目录属于内部实现的一种体现。如果你遇到解压后的 node_modules 里到处是下划线通常说明这个 node_modules 是从别的环境打压缩包拷贝进来的而不是在当前机器上通过npm install正常生成的。因为正常生成的 node_modules 里的目录结构被 package-lock 严格约束所以名字基本是常规的。但压缩包传输或者跨平台迁移的时候npm 会重新解析并调整为带下划线的嵌套结构这可能导致软链接或路径引用失效。在离线内网环境下的正确做法是在内网开发机上初始化项目后执行npm install --offline前提是你事先已经通过离线缓存方式导入了需要的包比如用npm pack把依赖打成 tgz 手动安装或者用 verdaccio 搭一个内网私有 npm 仓库。不要随随便便从外网拷贝一个 node_modules 过来解压直接用这几乎是“给自己挖坑”的代名词。如果只是拷贝 package.json 和 package-lock.json然后在内网通过npm ci重新安装依赖树会和锁文件严格一致这样最稳。提示离线环境建议提前用 verdaccio 搭一个内网 npm 仓库把外网源的包全部缓存进去。这个仓库能极大提升安装速度和稳定性也能避免很多玄学报错。4.3 一些常见报错的快速排查速查表我把最常被问到的问题整理成一个表方便你直接对照排查报错表现根本原因推荐解决方式npm 不是内部或外部命令/无法将“npm”项识别为 cmdletPATH 环境变量未配置或配置错误检查 Node.js 目录是否在 PATH添加后重启终端npm.ps1因为在此系统上禁止运行脚本PowerShell 执行策略拦截Set-ExecutionPolicy -Scope CurrentUser RemoteSignednpm error code EPERM文件被占用或权限不足关闭所有 Node 进程、以管理员身份运行终端npm error code ENOTFOUND/ETIMEDOUT网络无法访问 registry切换淘宝镜像源或配置代理npm warn deprecated node-domexception1.0.0依赖的某个子包版本过旧被标记废弃属于警告不影响安装可升级对应依赖npm warn using --force recommended protections disabled使用了--force安装绕过了完整性校验除非明确知道原因否则不建议使用--forcenpm run dev报错本地环境问题居多不确定原因时先看错误堆栈优先删除 node_modules 和 lock 文件后重装npx: command not foundnpx 未随 npm 正确安装检查 Node.js 安装完整性重装 Node.js 或手动补装npm ci与 package-lock 不一致手动改了 package.json 但没更新 lock执行npm install重新生成 lock 后再用npm cinpm install 每次构建都要做吗这是理解问题不是报错正常情况利用 lock 缓存CI 中可用npm ci加速4.4 关于npm ci和npm install的取舍聊到“每次构建都要做吗”这个热搜词我应该顺便展开说下npm install和npm ci的差异。npm ci是 npm 5.7.0 引入的专门用于 CI/CD 流程。它的特点是严格按照 package-lock.json 安装依赖不会自动更新 lock 文件不会做任何“智能解析”安装速度通常比npm install快很多。如果你在 CI 流水线里每次跑npm install它理论上会花时间做依赖解析和版本协商而且如果 package.json 和 lock 有偏差它还可能悄悄改掉 lock。正确做法是 CI 里用npm ci这个命令在 node_modules 存在时会先自动删除再重装确保环境干净可复现。这跟你本地「改动 package.json 后执行 npm install 更新 lock」是完全不同的使用场景后者才是npm install的典型场景。我见过很多团队把这两个命令混用导致 CI 构建耗时增长偶尔还会出现“本地跑得好好的CI 上就拉不起来”的诡异问题很大概率就是 lock 和 package.json 不一致造成的。4.5 npm 的 deprecated 警告到底需不需要管热搜里有一条特别典型的警告npm warn deprecated node-domexception1.0.0: use your platforms native dome这类deprecated警告在npm install时经常刷屏。它的意思是这个包node-domexception已经过时上游作者在 registry 里标记了弃用说明建议你换平台原生的 DOMException。很多新手看到这个警告会慌担心是不是安装失败了。其实 deprecation 警告只是 npm 在告诉你“这个包不建议继续在你项目里作为新依赖引入”但如果它只是某个常用依赖的间接依赖transitive dependency你一般不需要特意处理。等到这个间接依赖的维护者升级了它的依赖这个警告自然会消失。需要警惕的是 npm 使用--force时提示的 “recommended protections disabled”。这说明你在安装时绕过了某些安全保护真正需要关注的是为什么要加--force才能安装成功。大多数情况是因为依赖冲突暴力加--force只是强行装进去了后面运行时报错才更头疼。遇到依赖冲突时看完整错误信息拿到到底是哪几个包打架再决定升级版本还是通过overrides字段强制指定版本不要一上来就--force。5. 发布 npm 包时涉及的高频坑这不是 npx 的直接内容但热搜词里多次出现“发布npm包”而且很多人虽然知道npm publish却总是因为镜像源、命名、文件管理的问题反复失败。我在这里就相关度比较高的几个点集中说一遍。5.1 发布包之前先确认 registry 是官方源发布 npm 包的第一步也是最重要的检查项确认你的 registry 指向的是官方源不是淘宝镜像。npm config get registry如果是https://registry.npmmirror.com/那直接执行npm publish会报错。切换到官方源npm config set registry https://registry.npmjs.org/发布完可以再切回淘宝源也可以把需要发布的项目里单独建一个.npmrc文件只对当前目录生效内容写registryhttps://registry.npmjs.org/这种方式只在发布目录生效不影响全局开发环境的镜像配置比反复手工切换清爽很多。5.2 包名与版本号校验npm publish还有几个高频拦路虎包名重复这个包名如果已经被别人注册过会报npm ERR! 403 You do not have permission to publish xxx。尤其是那种很常见的单词早就被别人占了。可以先执行npm view 包名查看是否已存在。版本号重复同一个版本号不能重复发布。你现在 package.json 里的version字段如果和线上已发布过的版本撞了会直接报 403。发布前先改 version 字段用npm version patch这种命令自动递增也比较方便。文件白名单用files字段配置发布时要包含哪些文件避免把node_modules、测试文件、打包缓存等一并发布出去。包名、版本号、main/module 字段、description 和关键词这些基础信息写齐全也能减少后续使用者的成本。登录状态npm publish前必须登录npm login会提示输入用户名、密码、邮箱。平时本地一般建议带上用户名邮箱环境变量身份执行避免打包机没有登录状态导致发布失败。5.3 发布私有包公司内部的业务组件一般不建议直接发布到公共 npm registry。常见做法是搭建私有仓库Verdaccio、Nexus、JFrog 均可然后在项目中配置一个.npmrc指向私有仓库地址。这样既能享受 npm 标准的依赖管理又不会暴露源码。发布私有包之前注意看一个字段private。如果你还没想好要不要发布把这个字段设为truenpm 会拒绝任何形式的 publish。等真正要发布时再把它删掉这个字段在调试发布配置时很有用能防止手滑把不该公开的包发出去。6. 最后聊聊我自己的使用习惯回到npx和npm这个话题本身。我自己的习惯可以用一句话概括凡是需要长期存在于项目里的依赖一律用npm install -D之类的命令写进 package.json凡是只需要临时运行一次的工具一律用npx。这个原则我坚持了很久带来的最大好处是全局环境保持干净项目之间不会相互干扰接手的同事也能通过 package.json 非常清楚地知道项目到底依赖哪些包、用哪个版本的命令。我见过太多人习惯全用-g全局安装最后机器上几十个全局包根本不知道哪个项目需要哪个遇到版本冲突只能硬着头皮清理那真是灾难现场。另外一个小技巧如果你不想每次执行npx弹出来问是否安装可以加--yes参数跳过确认npx --yes cowsay hello在 CI 或者自动化脚本里写npx命令时最好带上--yes避免流水线卡在交互确认这一步。反过来如果你担心安全问题可以用--no-install让 npx 只用本地已安装的包找不到就直接报错而不会去下载。这个参数在审查安全风险时特别实用。我早期也犯过一个错误一直以为npx就是“npm 的升级版”所以所有命令都改成npx开跑。后来才意识到npx压根儿不是包管理器它只是负责“跑命令”的真正的依赖管理和安装还得靠npm来完成。这两个工具组合在一起才是完整的 Node.js 开发体验。搞懂这一点之后很多命令为什么会做出当前行为就一目了然了。