最近被问得最多的问题,几乎都绕不开这两句话:“nvm 怎么下载安装?”“Node.js 怎么装?”有人第一次接触,连这两个东西的关系都没搞清楚;有人已经在官网装过 Node.js,结果项目一要切版本就抓瞎;还有人卡在 c:\users\administrator>nvm install 22.13.1 之后一直显示 downloading node.js version 22.13.1,不知道是成功还是失败。
这篇文章就是来解决这些问题的。我会从“为什么需要 nvm”讲起,把 Windows 下的完整安装过程、常用命令、版本切换、环境变量、卸载重装这些环节全部过一遍,顺便把几个高频报错——包括 node.js v24.19.0 is not yet released or is not available、GUI 工具提示 node.js not found、卸载报错 2053——的排查思路都拆开讲清楚。适合完全没装过 Node.js 的新手,也适合已经装了 Node.js 但被版本问题折磨过、想用 nvm 重做一遍的人。
1. 为什么坚持用 nvm 而不是直接去官网装 Node.js
1.1 node.js 到底在干什么,为什么需要版本管理
Node.js 是一个 JavaScript 运行时环境,简单说就是让 JavaScript 不再只活在浏览器里,而是可以跑在操作系统上做服务端开发、命令行工具、自动化脚本、桌面应用构建这些事情。绝大多数前端工程化工具,比如 Webpack、Vite,都是跑在 Node.js 上的。安装 Node.js 时通常还会带上 npm,那是 JavaScript 世界的包管理器,用来下载和管理第三方依赖。
版本管理这件事,新手最容易忽略。很多人以为“装个最新的 Node.js 就万事大吉”,但实际情况是:不同的项目对 Node.js 版本的要求可能是完全冲突的。老项目可能只兼容 Node 14 或 16,新项目可能要求 20 以上,某个自动化工具甚至会在 package.json 的 engines 字段里写明 node >=22.22.3 <23 或 >=24.15.0 <25 这样的严格范围。一旦你机器上只有一个版本,就会陷入“装新版跑不了老项目,换回老版又跑不了新项目”的困境。
1.2 需要频繁切换版本的现实场景
我见过最多的几个场景,基本可以覆盖 90% 的版本切换需求。
第一是老项目维护。你手上可能有一个两年前的项目,依赖里锁了 Node 16,一升级到 Node 20 就出现原生模块编译失败、内存溢出或某个包直接抛错。这时候你不会想去改项目,你只想让环境回到当年那个版本。
第二是多个新项目并行。有的项目用 Node 18 就够,有的项目初始化脚手架时要求 Node 22,还有的新工具对版本卡得特别死,比如某个开源工具要求 node >=22.22.3 <23,你用 22.13.1 都不让跑。如果每个项目都对应一个 Node 版本,没有 nvm,就只能来回卸载重装,一次至少折腾半小时。
第三是特殊系统环境。比如一些老电脑还在用 Windows 7,高版本 Node.js 官方已经不提供支持了,你只能装低版本。这种机器上更需要 nvm 让你随时在可用版本之间切换。
直接去官网下载安装包,相当于给整台机器绑定一个 Node 版本;nvm 做的事情则是让多个版本平行存在,需要哪个就切哪个。这一层想通了,后面的安装操作才会有意义。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装前先花五分钟把环境查一遍,不然装完就翻车
2.1 看看电脑上是不是已经装过 Node.js
很多人在装 nvm 之前机器上已经有 Node.js 了,可能自己都忘了。如果不先清理干净,装完 nvm 后很可能出现版本指向混乱:node -v 显示的到底是官网装的版本还是 nvm 管的版本,完全说不清。
先打开命令行(Win+R 输入 cmd 回车),执行:
bash复制node -v
npm -v
如果输出版本号,说明已经装过。这时候建议先把原来的 Node.js 卸载掉,再装 nvm。Windows 的卸载入口在“设置 -> 应用 -> 安装的应用”里找到 Node.js,点卸载。卸载完之后还要检查两个残留位置:
C:\Program Files\nodejs目录是否还存在- 环境变量 PATH 里是否还有
C:\Program Files\nodejs这样的记录
有就手动清理掉。这一步非常关键,我之前见过有人没卸干净,结果 nvm 的符号链接一直起不来,nvm use 命令显示成功,但 node -v 还是老版本,查了半天才发现是旧路径在 PATH 里排在更前面。
2.2 安装路径别带空格和中文
这条是 Windows 下安装 nvm 最容易踩、却最不容易被注意到的坑。
nvm 在 Windows 上是通过符号链接(symlink)来切换版本的,它会把一个目录链接到当前激活的 Node 版本目录。符号链接对路径非常敏感,一旦路径里出现空格或者中文,很多工具在解析路径时就会出问题。我自己就见过有人把 nvm 装进 C:\Program Files\nvm,结果 nvm use 时创建链接失败,报错信息还特别隐晦。
建议安装路径使用纯英文、无空格的短路径,比如:
text复制C:\nvm
或者:
text复制D:\dev\nvm
同样,后面 nvm 管理 Node.js 版本的目录也建议放在同一类干净路径下。
2.3 下载 nvm 安装包时怎么选版本
Windows 上用的 nvm 其实是 nvm-windows 这个发行版,它和 Linux/macOS 上用的 nvm-sh/nvm 并不是同一个项目,但命令设计基本一致。下载要去项目官方 GitHub 的 Releases 页面,认准 nvm-setup.exe 这个文件。
这里的经验是:优先下载 nvm-setup.exe,不要下载 nvm-noinstall.zip。nvm-setup.exe 是图形化安装向导,会帮你自动配置环境变量;nvm-noinstall.zip 是绿色版,需要手动配环境变量,虽然也能用,但对新手不够友好。
另外注意系统位数。现在基本都是 64 位系统,下载时看清楚文件名里有没有 x64 标识。如果你的网络访问 GitHub 很慢,可以考虑通过可以访问的镜像站或加速下载服务来拉取安装包,但下载完务必核对一下文件签名或者至少确认文件大小正常,避免拿到损坏的安装包。
3. Windows 下安装 nvm 的实操过程,每一步都说清楚
3.1 安装向导里两个路径别选错
运行 nvm-setup.exe 之后,安装向导会依次让你确认两件事。
第一个界面是选择 nvm 本身的安装目录。这里按上面说的,改成 C:\nvm 或者 D:\dev\nvm 这类路径,不要用默认的 C:\Users\你的用户名\AppData\Roaming\nvm,倒不是说不能用,而是有些工具在带用户名和空格的路径下表现不稳定。
第二个界面是选择 Node.js 版本存放目录。这个目录是你用 nvm install 下载各个 Node.js 版本的物理存放位置,建议直接放到 nvm 安装目录下,比如:
text复制C:\nvm
如果你第一个目录选了 C:\nvm,第二个界面一般会自动带出 C:\nvm,保持默认即可。
后面就是一路 Next 和 Install。安装结束后,先不要急着打开终端测试,继续往下看环境变量这一步。
3.2 装完先检查环境变量,再开新终端
nvm-windows 安装向导正常情况下会自动写入两个环境变量:
text复制NVM_HOME 指向 nvm 安装目录,比如 C:\nvm
NVM_SYMLINK 指向 Node 版本符号链接目录,比如 C:\nvm
同时会在 PATH 中追加:
text复制%NVM_HOME%
%NVM_SYMLINK%
不过自动配置偶尔会失效,或者你用的是绿色版需要手动配置。所以在正式使用前,最好手动确认一下:右键“此电脑 -> 属性 -> 高级系统设置 -> 环境变量”,在系统变量里看有没有上面这两个变量。没有就手动新建,然后在 PATH 里把 %NVM_HOME% 和 %NVM_SYMLINK% 加进去。
这里有个非常关键的细节:环境变量改完之后,所有已经打开的命令行窗口都不会生效,必须新开一个终端窗口。很多新手卡在“我明明装了 nvm 却提示不是内部或外部命令”,八成就是没开新窗口。
3.3 第一次验证:nvm version 和 nvm list
新开一个 cmd 或 PowerShell 窗口,先执行:
bash复制nvm version
如果输出类似 1.1.12 这样的版本号,说明 nvm 本体已经装好。接着执行:
bash复制nvm list
正常情况下会输出一句类似“No installations recognized”的提示信息,意思是当前还没有安装任何 Node.js 版本。这是正常的,别慌。
如果 nvm version 直接报“不是内部或外部命令”,按顺序做三件事:第一,确认环境变量是否真的写进去了;第二,确认你用的是新开的终端;第三,重启电脑再看一次。这三步能解决绝大多数“nvm 装完却不能用”的问题。
4. 第一次用 nvm 装 Node.js:命令手册和常见输出
4.1 最常用的命令一张表讲清
nvm 的日常命令其实非常少,我整理了一张表,够用 90% 的场景:
| 命令 | 作用 |
|---|---|
nvm list |
查看本机已安装的所有 Node.js 版本 |
nvm list available |
查看远程可下载的 Node.js 版本列表 |
nvm install <版本号> |
安装指定版本,如 nvm install 22.13.1 |
nvm use <版本号> |
切换当前使用的版本 |
nvm current |
查看当前正在使用的版本 |
nvm alias default <版本号> |
设置新开终端时默认加载的版本 |
nvm uninstall <版本号> |
卸载指定版本 |
这里特别提醒:nvm install 后面尽量写完整的三位版本号,比如 22.13.1,不要只写 22。虽然某些场景下 nvm 能解析大版本号,但 Windows 版 nvm 对模糊版本的支持并不稳定,写完整版本号能少踩很多坑。
4.2 一段真实的安装输出,拆开看每行什么意思
很多人搜索“nvm 下载安装教程”就是因为在命令行看到了类似这样的输出:
text复制c:\users\administrator>nvm install 22.13.1
Downloading node.js version 22.13.1 (64-bit)...
Complete
Creating new symlink...
Done
我来逐行解释一下这段输出的含义。
第一行 c:\users\administrator>nvm install 22.13.1 是你输入的命令,意思是让 nvm 安装 22.13.1 这个版本。第二行 Downloading node.js version 22.13.1 (64-bit)... 表示 nvm 正在从配置的镜像源下载对应的 Node.js 压缩包。此时如果网络正常,几秒到几分钟后会看到第三行 Complete,表示下载完成。紧接着 Creating new symlink... 和 Done 表示 nvm 正在创建指向这个新版本的符号链接,并最终完成。
看到 Done 之后,继续执行:
bash复制nvm use 22.13.1
node -v
npm -v
node -v 输出 v22.13.1,npm -v 输出对应的 npm 版本号,就说明安装成功了。
如果你的命令卡在 Downloading node.js version... 这一行超过五分钟还没动静,那基本可以断定是网络问题,往下看 4.3 的镜像配置方案。
4.3 下载卡住、超时怎么办:修改 settings.txt 镜像源
nvm-windows 的下载地址配置在安装目录下的 settings.txt 文件中。默认内容大致长这样:
text复制root: C:\nvm
path: C:\nvm
你可以在这个文件里增加镜像源配置。把 Node.js 的下载源和 npm 的下载源指向国内镜像,下载速度会有质的提升。示例配置如下:
text复制root: C:\nvm
path: C:\nvm
node_mirror: https://npmmirror.com/mirrors/node/
npm_mirror: https://npmmirror.com/mirrors/npm/
保存后关掉所有终端,重新打开,再执行一次 nvm install 22.13.1。
node_mirror 控制的是 Node.js 本体压缩包从哪里下载,npm_mirror 控制的是安装完 Node.js 后自动下载 npm 的源地址。只配前者不配后者,有可能出现 Node.js 装好了但 npm 装不上的情况。如果你用的是其他镜像,替换成对应地址即可。
5. 版本安装失败的完整排查链路:从 downloading 到 not yet released
5.1 先分清是版本号问题还是网络问题
安装 Node.js 版本失败,本质上只有两类原因:一类是版本号写得不对,另一类是网络下载出问题。
版本号问题典型报错长这样:
text复制error installing 24.19.0: node.js v24.19.0 is not yet released or is not available
网络问题典型表现是长时间卡在 Downloading node.js version...,或者下载到一半直接报连接失败、超时。
所以遇到报错,第一步不是去改镜像或者翻日志,而是先确认你输入的版本号是不是真实存在。最快的办法是执行:
bash复制nvm list available
这个命令会拉取远程版本列表,你能直接看到当前可下载的版本号。如果列表里根本没有 24.19.0,那后面排查网络问题都属于白费力气。
5.2 “not yet released or is not available” 的真实原因
那句 node.js v24.19.0 is not yet released or is not available 在网络上出现频率很高,很多人的第一反应是自己网络有问题,其实不是。
这个报错的机制是:nvm 去镜像的版本索引里查找你输入的版本号,如果这个版本号不在索引中,它会提示“还没发布或不可用”。常见原因有三个:
- 你写了一个未来版本号。比如 Node.js 24 系列还只发布到某个小版本,你随手写了 24.19.0,但实际并没有这个版本。
- 版本号拼写错误。比如把 22.13.1 写成 22.13.10,或者把 20.11.0 写成 20.11。
- 镜像源同步延迟。某些镜像站更新不及时,新版本在官网已经发布,但镜像索引里还没出现。
对应的解决办法也很直接:用 nvm list available 确认真实版本号;或者直接打开 Node.js 官网的下载目录(或你配置的镜像站)核对一下最新版本号。不要凭感觉写版本号,这是最省时间的做法。
5.3 排查顺序:从版本列表到手动兜底
如果版本号确认没问题,但还是下载失败,按下面这个顺序排查效率最高:
- 检查
settings.txt里配置的镜像地址在浏览器里能不能正常打开。 - 用浏览器直接访问镜像站里对应版本的压缩包地址,看能不能下载下来。
比如 Node.js 22.13.1 在镜像站的地址通常长这样:
text复制https://npmmirror.com/mirrors/node/v22.13.1/node-v22.13.1-win-x64.zip
能下载说明网络通,不能下载就换一个镜像源或者检查本机网络、安全软件是不是拦截了压缩包下载。
- 换一个镜像源再试。
- 如果上面的方法都不行,还有一个非常实用的手动兜底方案:
先去镜像站把对应版本的 Windows zip 压缩包手动下载下来,然后在 nvm 的安装目录下新建一个目录,命名规则是 v22.13.1(注意带小写 v),把压缩包里的文件全部解压到这个目录中。最后执行:
bash复制nvm use 22.13.1
nvm 会直接识别这个已经存在的版本目录。这个方案在我手上救过好几次急,尤其是在网络环境比较复杂、命令行下载总是断流的场景下,比反复重试命令行要可靠得多。
6. 切换版本后的头号问题:全局包去哪了
6.1 全局包不是丢了,是跟版本走了
用 nvm 一段时间后,大多数人会遇到这样一个现象:你之前用 Node 18 的时候全局装过 yarn、pnpm、@nestjs/cli 这些工具,一切换到 Node 22,再敲 yarn -v 就提示“不是内部或外部命令”。
第一反应往往是“坏了,全局包被删了”。其实没有,它们还在原来的位置,只是对你当前这个 Node 版本“看不见”了。
原因在于 npm 的全局包是安装在当前激活的 Node 版本对应目录里的。不同 Node 版本各自维护一套全局包空间,互不相通。你用 Node 18 装的全局包,装进了 Node 18 的目录;切到 Node 22 后,PATH 里生效的是 Node 22 的目录,自然找不到之前那些命令。
6.2 用 npm root -g 和 where node 理解路径
理解这个机制最快的方式,是用两条命令亲自验证一下。
先执行:
bash复制nvm current
确认当前版本。然后执行:
bash复制npm root -g
这条命令会输出当前版本的全局包安装目录。你可以先切到 Node 18,执行一次,再切到 Node 22,再执行一次,会发现两个路径完全不一样。
再执行:
bash复制where node
这条命令会列出系统 PATH 中所有找到的 node.exe 路径,排在第一位的才是实际生效的。用 nvm 管理的环境下,这里的路径应该指向 nvm 的符号链接目录,比如 C:\nvm\node.exe。如果这里出现的是 C:\Program Files\nodejs\node.exe,说明你机器上还残留着旧版 Node.js 的环境变量,需要回到第 2 节清理掉。
6.3 迁移全局包的实用办法
既然全局包跟版本走,那切换版本后要做的就是“重新装一遍”。
如果你只有一个固定的全局包清单,最简单的做法是切换到新版本后,把之前装过的全局包再执行一次安装。比如:
bash复制npm install -g yarn pnpm @nestjs/cli typescript ts-node
如果全局包比较多,可以先把旧版本里的全局包列表导出来:
bash复制npm list -g --depth=0
然后对照这个列表在新版本里批量安装。
另外,我自己的习惯是把“全局包数量控制在最小”。像 typescript、eslint 这类工具,如果能装进项目的 devDependencies,就不要装全局。因为全局包数量越少,切换 Node 版本时的迁移成本就越低。像 pnpm 这种自带版本管理能力的工具,用官方提供的安装方式独立管理,也比挂在某个 Node 版本下更省心。
7. 软件报错 node.js not found,问题往往不在 Node
7.1 先别重装,按这个顺序排查 GUI 工具的报错
有一个非常典型的报错场景:某款 GUI 工具下载完成后打开,直接弹出一句:
text复制node.js not found (please save below and restart)
看到这句话,不要急着重装 Node.js。绝大多数情况下,你的 Node.js 本身是好的,只是这个 GUI 工具没能从环境变量里找到它。
原因是这样的:GUI 工具通常在系统启动时读取环境变量,如果你在安装 nvm 或 Node.js 之后没有重启电脑,或者安装期间环境变量发生了变化,工具的进程里拿到的还是旧的环境变量。它自然找不到 node.exe。
排查步骤按顺序来:
- 新开一个终端,执行
node -v,确认命令行下 Node.js 可用。 - 右键“此电脑 -> 属性 -> 高级系统设置 -> 环境变量”,确认 PATH 里包含 nvm 符号链接路径。
- 如果命令行下正常,但工具还是报找不到,说明工具的进程环境是旧的,重启一下工具,再不行就直接重启电脑。
- 有些工具支持自定义 Node.js 路径,找到设置项,把 Node.js 路径指向 nvm 符号链接目录即可。
我之前帮人处理过一个类似“cc gui 下载完,显示 node.js not found”的问题,操作到最后其实就是重启了一下电脑就好了。这类问题绕了一大圈,最后往往是最简单的步骤解决。
7.2 PATH 配置顺序和“where node”的结果
PATH 环境变量里可以同时存在很多条路径,终端在查找命令时会从左到右依次查找,第一个命中的就是最终执行的程序。这个顺序非常关键。
比如你的 PATH 里同时有:
text复制C:\Program Files\nodejs
C:\nvm
那么执行 node -v 时,系统会先去 C:\Program Files\nodejs 里找 node.exe,找到了就根本不会管 nvm。这就会造成一种很诡异的现象:你 nvm use 16 明明显示成功,where node 显示的却是 C:\Program Files\nodejs\node.exe,实际跑的还是老版本。
所以在装有 nvm 的机器上,PATH 里不应该再保留任何指向具体 Node.js 安装目录的路径。如果你发现 where node 的结果不对,优先检查并清理 PATH,而不是反复重新安装。
7.3 打包到没有 Node 的电脑上怎么办
还有一个高频需求,跟版本切换不直接相关,但也经常出现在“Node.js 下载安装”相关关键词下:开发机正常,但要交付给一台没有安装 Node.js 的电脑,程序跑不起来。
这种情况有几种处理思路。第一种是把 Node.js 应用用打包工具做成独立可执行文件,比如 pkg 或 nexe,产物是一整个 exe,目标机器不需要安装 Node.js。第二种是目标机器也装一套 nvm + Node.js,把运行环境迁移过去。第三种是用容器或镜像方案,把应用连同 Node.js 运行时一起封装起来。
我想强调的是,这类需求恰恰说明“在开发机上用 nvm 管理版本”很有价值:你可以精确地在开发机上复现目标机器将要运行的 Node.js 版本,避免出现“开发用 Node 22 测得好好的,交付到目标机器只有 Node 18,一跑就崩”的情况。版本一致性这件事,越早管理,后面亏吃得越少。
8. 卸载重装与升级:2053 报错和 PowerShell 下的清理建议
8.1 卸载 Node.js 报错 2053,先做修复而不是硬删
Windows 下卸载 Node.js 时遇到错误码 2053,是一个比较常见的现象。很多人第一反应是去强制删除安装目录,结果越删越乱。
2053 这个错误码,通常意味着 Windows Installer 认为当前安装状态已经损坏,或者卸载所需的配置信息不完整。还可能跟注册表残留、安装缓存损坏、安全软件锁定文件有关。
我的建议是:先不要强制删除文件夹,优先尝试两种方法。
第一种,重新运行 Node.js 的原安装包,看安装向导里有没有“Repair/修复”选项。如果有,先执行修复,修复后再卸载。第二种,使用微软官方的“程序安装和卸载疑难解答工具”来扫描并修复损坏的卸载状态。
如果以上都不行,才考虑在管理员权限下用 PowerShell 查询安装信息并尝试卸载。但这一步对新手不够友好,操作前建议先备份注册表。
8.2 彻底卸载 nvm 与 Node.js 的推荐顺序
如果你想清空整台机器上的 nvm 和所有 Node.js 版本,重新来一遍,推荐按这个顺序操作:
- 打开终端,执行
nvm list查看所有已安装版本。 - 逐个执行
nvm uninstall <版本号>,把 nvm 管里的 Node.js 版本全部移除。 - 关闭所有终端窗口和依赖 Node.js 的程序。
- 在系统环境变量里删除
NVM_HOME、NVM_SYMLINK,并清理 PATH 里相关的%NVM_HOME%、%NVM_SYMLINK%。 - 删除 nvm 安装目录。
- 清理 npm 相关缓存目录:
text复制%APPDATA%\npm
%APPDATA%\npm-cache
- 重启电脑。
这个顺序的关键点是“先卸载软件,再删目录,最后清理环境变量”。顺序反了,容易出现卸载程序找不到安装记录、资源管理器还在占用文件的情况。
8.3 WSL 里的 nvm 与 Windows 下不是一回事
如果你用的是 WSL(Windows Subsystem for Linux),需要注意:WSL 里面是一个 Linux 环境,Windows 上那个 nvm-windows 的 exe 安装包在 WSL 里不能直接用。
WSL 里安装的是 Linux 版 nvm,安装方式是用 curl 拉取脚本:
bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
如果你的网络访问该地址不顺畅,可以找可用的镜像源拉取
