我在 Windows 上折腾 Node.js 这些年前前后后换过几十个版本。有一阵子全靠官网安装包来回卸载重装，结果就是各种环境冲突，直到用上 nvm-windows 才算是真正解脱。这篇就把 Windows 下 nvm 的完整玩法一次讲清楚，从安装、环境变量，到日常切换版本、npm 全局配置、镜像加速，再附带一堆常见坑的排查思路。刚接触 Node.js 的新手可以照着一步步做，被多版本切换折磨过的老开发也能从中找到几个以前没注意过的细节。
1. 为什么 Windows 开发者需要一个 Node.js 版本管理器
1.1 多版本并存才是真实世界的常态
前阵子团队接了个维护多年的老系统，后台还在 Node 14 上跑，新建的接口服务又要求 Node 18+，我自己想验证一个新特性还得切到 Node 22，一台机器三个版本来回倒腾。如果没有 nvm，这种需求根本没法体面地落地。
没有版本管理器的时候，大家的常规操作是：从官网下载安装包，装新版，发现旧项目崩了，卸载重装旧版；下次新项目又急用新版本，再卸载、再安装。运气好一两个小时，运气差还得处理全局 npm 包全部重装、环境变量被改乱、node -v输出不对等一系列遗留问题。我见过有人一年下来系统里积了七八个 nodejs 临时目录，全是这种循环卸载留下的“尸体”。
nvm 的出现就是来终结这个局面的。它的本质是在系统里维护多个彼此隔离的 Node.js 版本，通过一个软链接随时切换当前生效版本。装完 nvm 之后，日常最长用的命令就三条：nvm install装版本，nvm use切版本，nvm list看已装列表。整个操作全程命令行，不碰图形界面，也不碰环境变量编辑器，干净利落。
1.2 先分清 nvm 和 nvm-windows
这里必须先提醒经常搜教程的读者，网上大量 nvm 安装资料都是针对 macOS 和 Linux 的，比如 curl 拉一个 shell 脚本再 source 一下，那套东西在 Windows 上基本不能用。Windows 下我们说的是 nvm-windows，一个用 Go 写的独立开源项目，作者是 coreybutler，GitHub 仓库名就叫 nvm-windows。
nvm-windows 的命令和正统 nvm 保持了很大程度的一致，常见的有 list、install、use、uninstall、current、alias 这些，所以如果你以前用过 Unix 系的 nvm，迁移成本几乎为零。它的工作原理也值得理解一下：安装时会指定一个 root 目录存放所有下载的 Node.js 版本，同时创建一个软链接 NVM_SYMLINK（默认是 C:\Program Files\nodejs）。nvm use本质上是把这个软链接重新指向目标版本目录。理解这条链路，后面排查任何 node 命令失效的问题，都会特别有方向感。
下载 nvm-windows 我建议只认准 GitHub Releases 页面，文件名选 nvm-setup.exe。那些“一键安装 nvm”的第三方站点、网盘资源我是从来不信的，装这类开发工具，来源越干净越好。
2. 动手安装前，先把旧环境处理干净
2.1 卸载旧版 Node.js：这一步别偷懒
如果你机器上已经装了 Node.js，不管是官方安装包装的还是绿色解压版，我建议先彻底清理再上 nvm。原因在于 nvm-windows 是通过修改 PATH 加软链接来接管 node 命令的，如果系统里已经有一个真实的 C:\Program Files\nodejs，两者会直接冲突。最常见的现象就是nvm use明明提示成功了，node -v依旧输出旧版本。
清理步骤并不复杂。先在“设置 -> 应用”里正常卸载 Node.js；然后检查这几个残留目录，存在就删：C:\Program Files\nodejs、C:\Program Files (x86)\nodejs、%APPDATA%\npm、%APPDATA%\npm-cache。最后打开环境变量编辑窗口，把 PATH 里和 nodejs、npm 相关的历史项逐条删掉。全部操作完，新开一个命令提示符，敲node -v时如果提示“不是内部或外部命令”，说明清干净了。
提示：部分第三方软件安装过 Node 的运行时，清理时可能会连带影响它们。删 PATH 之前先把需要保留的项记下来。如果不确定哪条有用，宁可多截图再动手。
2.2 nvm-windows 安装过程：记住两个关键目录
双击 nvm-setup.exe 后，安装向导第一屏要你选择 nvm 安装目录。我强烈建议不要沿用默认的 C:\Users\你的用户名\AppData\Roaming\nvm。一是路径带用户名和空格，某些第三方脚本在找 node 路径时会出问题；二是用户目录的权限模型容易给后面nvm use添乱。我自己习惯装在 C:\nvm 或者 D:\DevTools\nvm，全英文、无空格、层级浅，一劳永逸。
第二屏是设置 Node.js 软链接目录，默认 C:\Program Files\nodejs，这个一般不用动。很多编辑器、IDE、全局工具默认就会去这个路径找 node，保持默认最省心。不过要注意，创建软链接需要写文件系统的权限，所以安装包尽量右键“以管理员身份运行”，杀毒软件如果拦截询问，放行即可。
装完以后，新开一个管理员命令提示符，输入nvm version，能输出版本号就说明安装成功。这时候打开 C:\Program Files，应该能看到 nodejs 这个条目，上面带一个小箭头图标，表示它是一个符号链接。如果这个目录不存在，多半是安装时权限不够，后面nvm use也会失败，趁早重装。
2.3 看一眼 settings.txt：nvm 的配置文件是纯文本
nvm 安装目录下有一个 settings.txt，内容约长这样：
root: C:\nvm path: C:\Program Files\nodejs arch: 64 proxy: noneroot 是版本库目录，path 是软链接目标，arch 是默认架构。如果网络情况不好，还能在这个文件里追加 node_mirror 和 npm_mirror 两行，指向国内镜像源，这个在后面第 4 部分会细说。修改这个文件之前，先关掉所有正在使用 node 的终端，不然可能出现读取到旧配置的问题。
有一点需要提醒：arch 只是默认架构，安装时也可以临时覆盖，比如nvm install 18.20.4 32就会装 32 位版本。当前主流的 Windows 都是 64 位，保持默认 64 基本就行，只有那种跑老工具链的人才可能用到 32 位，那也没问题，nvm 会同时管理两套架构的版本。
3. 核心操作：安装、切换与删除 Node.js 版本
3.1 用 nvm list available 查版本，再 nvm install 装版本
安装版本之前，先看一眼远端有哪些版本可用，命令是nvm list available。它会按大版本分组把当前可安装的版本列出来，还专门标了 LTS 和 Current。这个列表本质上是从 Node 官方版本索引抓取的，偶尔会有点缓存延迟，出现最新版比官方晚几个小时是正常的。
确定好版本号后就执行nvm install，比如nvm install 18.20.4。nvm 会去官网下载对应的 zip 包，自动解压到 root 目录。这里我建议按三位完整版本号安装，别只写大版本，比如nvm install 18，那样虽然也能自动解析到最新补丁版，但不利于以后复现和排查。带不带 v 前缀都可以，nvm install v18.20.4也能识别，我习惯不带。
日常搭配方面，我的典型配置是一套 LTS 版本当主力开发环境，一套当前最新版用来验证新语法，再留一套老项目锁定的版本，比如 14.21.3。三套并行走天下，九成场景都覆盖了。
3.2 nvm use 切换版本：权限是最大的坑
版本装好以后，切换用nvm use 18.20.4，成功后会提示 Now using node v18.20.4 (64-bit)，这时候当前终端的node -v和npm -v都会变成对应版本。但这里有个几乎所有新手都会踩的坑：nvm use必须管理员权限，否则会提示“无法创建软链接”或者干脆静默失败。
还有个更隐蔽的现象：普通权限终端里nvm use显示成功了，但node -v还是旧版。这是因为软链接没建成功，PATH 指向的 C:\Program Files\nodejs 没有任何变化。遇到这种情况别研究别的了，关掉终端，右键“以管理员身份运行”重新打开，再执行一次nvm use，立刻正常。
切完以后建议顺手敲nvm current确认，也可以用nvm list看，当前版本行会标 * 号或 current 字样。如果项目对 npm 版本也有要求，再敲一下npm -v确认一番。因为不同 Node 版本自带的 npm 差异挺大，Node 18 带的是 npm 9，Node 20 带的是 npm 10，版本不对可能导致某些工程脚本行为不一致。
3.3 删除版本、设置默认版本和别名
装的版本多了，磁盘占用不说，nvm list输出也会刷屏，不用的版本定期清理是对的。删除命令是nvm uninstall 14.21.3，唯一限制是当前正在使用的版本不能删，必须先切走再删。这个设计倒是很合理，防止手滑把正在运行的版本删了。
还有一个需要养成的习惯是设置 default 别名。nvm-windows 刚装完，默认不会自动选中任何版本，新开终端时 node 不可用，必须先nvm use一次。如果你希望每次打开终端就有可用的 node，执行nvm alias default 18.20.4，之后新终端会自动切换到这个版本。
alias 命令还可以自定义名字，比如nvm alias old 14.21.3，之后nvm use old就能切。团队协作里，我通常会在项目 README 里写清楚推荐的 Node 版本和切换命令，然后建议队友用 alias 简化操作，哪怕只有一两个人协作，也能省下不少沟通成本。
4. 配合 npm 的全局配置与镜像加速
4.1 npm 镜像源配置：国内开发者绕不开的一步
Node.js 装好了，如果 npm 默认源很慢，开发体验会立刻打折扣。国内最常用的替代源是 npmmirror（前身是淘宝镜像），registry 地址是 https://registry.npmmirror.com。
配置方式有两种。临时用一次可以在装包时加参数：npm install --registry=https://registry.npmmirror.com 包名。更推荐的是配置到全局：npm config set registry https://registry.npmmirror.com，之后这台机器的 npm 都走镜像。想确认当前源就执行npm config get registry，想还原官方源就npm config set registry https://registry.npmjs.org。
这里我想说点经验：镜像源和官方源数据同步有延迟，但 npm 生态下延迟影响很小。如果哪天镜像上确实找不到某个刚发布的包，可以临时加--registry参数从官方源拉一次，没必要来回切全局配置。另外，公司内网如果有自己的 npm 私服，把 registry 指到私服地址也一样，步骤完全相同。
4.2 全局包为什么一切换版本就“消失”
读者问最多的一个问题：我明明npm i -g装了全局包，怎么nvm use切个版本，包全不见了？我们先看事实：在 nvm-windows 环境里，执行npm root -g和npm prefix -g会发现全局目录是 C:\nvm\对应版本号\node_modules 这种格式。也就是说，每个 Node 版本都维护着自己独立的全局包目录，版本之间完全不共享。
这既是特性也算坑。特性在于不同版本可以用不同版本的全局工具，互不污染；坑在于你切到 Node 18，全局装个 yarn，再切到 Node 20，yarn 命令又没了，很容易给人一种“环境坏了”的错觉。想清楚这套机制后，你就不会再慌。
我的建议是：开发工具类全局包按需安装，项目依赖一律走本地 devDependencies。如果确实需要在多个版本上用同样的全局包，先把全局包列表导出来，切到新版本后批量安装。导出命令是npm list -g --depth=0，输出就是一行行“包名@版本号”，清洗一下喂给npm i -g就行。或者干脆只在 default 版本上维护一套完整全局包，其他版本保持最小化。
4.3 核对 node 和 npm 版本对应关系
有人会遇到“新项目 npm install 报 engine 警告”或者“某个命令在新 Node 上不兼容”，这往往和 npm 版本有关。升级当前 Node 版本自带的 npm，用npm install -g npm@latest。这条命令只影响当前 Node 版本，其他版本的 npm 不受影响，这正是 nvm 隔离环境的好处。
但注意别盲目升级到最新：新版 npm 可能会要求 Node 版本不能太低。比如你在 Node 14 环境下，把 npm 升到最新版，很可能直接报错，因为新版 npm 最低要求 Node 18+。稳妥的做法是装与当前 Node 大版本匹配的 npm 版本，比如 Node 18 用 npm@9 或 npm@10，Node 20 用 npm@10。敲npm install -g npm@10这种显式指定大版本的写法，可控性更强。我的原则就一句话：Node 版本不变，npm 够用就行，别追求最新。
5. 常见问题与排查技巧实录
5.1 node -v 提示“不是内部或外部命令”
出现这个提示，按顺序排查三件事。第一，安装完 nvm 后是否重开过终端？PATH 不是实时刷新的，新开的终端才会生效。第二，系统里有没有可用版本？先nvm list看列表，再nvm current看当前，如果 current 是空，说明还没有任何版本被选中，要么nvm use一次，要么设置 default 别名。第三，C:\Program Files\nodejs 这个软链接目录是否存在？如果不在了，多半是被安全软件清理了，管理员身份nvm use一下会自动重建。
这三步走完，九成问题能解决。剩下极少数情况是 PATH 里本来就有旧的 nodejs 路径在 nvm 路径之前，导致系统优先执行了旧 node，清理 PATH 时把旧项删掉即可。
5.2 nvm install 下载慢或卡住：把下载源切到镜像
nvm install默认从官方源下载，国内网络下若经常卡在进度条，最简单的方法是修改 settings.txt 加两行镜像配置：
node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/保存后重开终端，再执行nvm install就顺畅多了。原理也不复杂，nvm 下载的其实是 node-v18.20.4-win-x64.zip 这类压缩包，默认从 nodejs.org/dist 拉，改成镜像后只是换了个下载地址，解压和安装逻辑完全不变。如果改完镜像还是很慢，那就是镜像源高峰期拥堵，换个时段，或者手动把 zip 下载到 nvm 的 temp 目录再nvm install，也能识别。
5.3 报错 Node.js 版本 is not yet released or is not available
这个报错英文原文大概是Error installing 20.14.0: Node.js v20.14.0 is not yet released or is not available。遇到它先别急，绝大多数情况不是环境坏了，而是版本号不存在。比如输成了 18.99.99，或者远端索引还没同步最新版本。做法是nvm list available刷新索引，看列表里到底有没有这个版本，然后复制一个准确的版本号重装。如果索引一直不刷新，可以删掉 nvm 目录下的缓存文件再试，一般就正常了。
5.4 VSCode 终端切了版本没变化
VSCode 内置终端比较特殊，它会缓存整个环境变量和 shell 状态，nvm use切换后如果当前终端node -v没变，不用怀疑 nvm 坏了，直接重开一个新的集成终端，或者重启 VSCode。高频切换的话，也可以给 VSCode 配置多个终端 profile，每个 profile 预先执行好nvm use，启动即用。我自己就配了 default 和 legacy 两个 profile，分别对应不同项目，实测很省事。
5.5 常见问题速查表
| 现象 | 主要原因 | 快速解决 |
|---|---|---|
| node -v 提示不是命令 | PATH 未刷新或无版本生效 | 重开终端；nvm use 或设 default |
| nvm use 显示成功但版本不变 | 权限不足导致软链接失败 | 管理员终端重新 nvm use |
| nvm install 卡进度条 | 官方源下载慢 | settings.txt 配 node_mirror/npm_mirror |
| 切换版本后全局包消失 | 每版本独立全局目录 | 按版本装包或导出列表批量安装 |
| VSCode 终端版本没变 | 环境变量缓存 | 重启 VSCode 或新开终端 |
| 删除版本报错 | 删除的是当前使用版本 | 先 nvm use 其他版本再删 |
6. 团队协作里的版本管理经验
6.1 用 .nvmrc 固定项目 Node 版本
团队项目最常见的版本灾难是“我这跑得好好的，你那怎么不行”，一查原因，两个人的 Node 版本不一样。解决方案就是让项目带上 .nvmrc 文件，写入一行版本号，比如 18.20.4。很多工具链会自动读取这个文件，比如 nvm 配合某些 shell 插件会直接切换到对应版本。在 Windows 下，虽然没有那么顺滑的自动切换，但这个文件至少是一份明确的项目声明，配合 README 里写一句“先 nvm use，再 npm install”，团队里谁都不会踩空。
6.2 把 nvm 纳入环境初始化脚本
新电脑、新同事入职，配置开发环境是最容易出乱子的一环。我会把 nvm 安装、Node 版本安装、npm 镜像配置打包成一份脚本或者文档，粘贴即用。核心命令就那几条：安装 nvm、nvm install指定版本、nvm alias default设置默认版本、npm config set registry设置镜像源。花半小时把这些沉淀成团队标准，后续每台新机器都能在一个小时内进入开发状态，这笔账怎么算都划算。
6.3 我这些年用 nvm 的最终心得
如果只让我留三条建议，第一是“一台机器只维护一套 nvm，别混装任何版本的官方 Node”；第二是“全局包越少越好，项目依赖放本地”；第三是“切换版本就相信管理员终端里的输出，别被普通终端的假象骗了”。
这些年我在无数台 Windows 上配过 nvm，从 Win7 到 Win11，踩过的坑比文档多得多。但说到底，nvm 的价值就在于它把“多版本并存”这种看似复杂的事变成了三条命令。你现在花半小时把它配好，未来每年能省下的时间和烦躁情绪，绝对是超值的。
