1. nvm是什么，为什么Windows开发者离不开它
1.1 多版本共存的真实痛点
先讲一个我自己的经历。有一年我在维护一个老后台管理系统，用的Vue 2 + Webpack 4，锁定的Node版本是14.x。与此同时，新接手的自动化脚本项目要求Node 18以上，因为用到了新的fetch和原生测试框架。于是我的电脑上出现了这样一种循环：
- 打开老项目，npm install报错，提示node-sass不支持当前Node版本；
- 切环境变量，把Node从18改回14；
- 老项目跑起来了，新项目又开始报错，因为Node 14不支持新语法；
- 再切回来，来回折腾。
最崩溃的不是切版本本身，而是切完版本之后各种全局工具链不对齐。今天你用npm install -g装了个CLI工具，明天切换Node版本，这个工具就像凭空消失了。这种体验，我相信不只我一个前端碰到过。
nvm（Node Version Manager）解决的就是这个痛点。它允许你在同一台Windows机器上安装多个Node.js版本，每个版本独立存在，切换的时候只需一条命令，它会自动帮你管理PATH环境变量，让当前终端里激活的node和npm都指向你指定的版本。nvm-windows是nvm在Windows平台上的移植版本，虽然跟Linux/macOS上那个nvm略有差异，但核心思路完全一致。
1.2 nvm、nvm-windows与gnvm的选型对比
这里要说明一个比较容易混淆的点。大家在GitHub上搜nvm，出来的第一个仓库是nvm-sh/nvm，官方明确说明它只支持Linux和macOS，不支持Windows。Windows下真正能用的，是Corey Butler维护的nvm-windows（仓库名coreybutler/nvm-windows），目前版本已经到1.1.x，支持安装、卸载、切换、镜像配置等功能。
除了nvm-windows，早期还有gnvm这个国产工具，它的特点是支持从镜像源直接下载Node，国内下载速度不错，但更新频率相对低，生态和文档不如nvm-windows完善。
我个人的建议是：如果你不是有特殊历史包袱的老项目，直接选nvm-windows就够了。原因有三点：
- 社区活跃度高，Issue响应及时，遇到问题能较快找到解决方案；
- 命令设计贴近Linux/macOS上的nvm-sh，熟悉其他平台开发方式的同事上手快；
- settings.txt可以自定义下载镜像和代理，国内下载Node的速度不再是大问题。
2. 安装前准备与nvm-windows安装全流程
2.1 安装前必须做的三件准备工作
先别急着下载安装包，有几个准备工作做不好，后面会有一堆莫名奇妙的问题。
第一，卸载已有的Node.js。如果你电脑里已经装了Windows安装包版的Node.js，nvm-windows在安装时会提示检测到已存在的Node环境，你可以选择让它接管，但这往往会造成PATH里同时出现两套node，切换时旧版本总被优先调用。最稳妥的办法是先去控制面板或系统设置里的“应用”中卸载Node.js，顺手把下面的目录也清理干净：
- C:\Program Files\nodejs
- C:\Users\你的用户名\AppData\Roaming\npm
- C:\Users\你的用户名\AppData\Roaming\npm-cache
- 临时目录中残留的npm相关文件
第二，确认安装目录不要带空格和中文。nvm-windows对路径比较敏感，我见过因为装在C:\Program Files (x86)下导致nvm use命令失效的情况。建议统一使用C:\nvm这种干净路径，后面配置npm全局目录的时候也会省事很多。路径越短，出问题的概率越低，这算是我多次踩坑之后的一个心得。
第三，安装阶段暂时退出杀毒软件或放行nvm。nvm-windows安装时会创建符号链接，部分杀毒软件会把这一步误判为可疑操作，拦下来之后nvm install的符号链接就失败，导致node命令无法找到。装完再开启杀毒软件完全来得及。
2.2 下载与安装nvm-windows
下载地址是GitHub上coreybutler/nvm-windows仓库的Releases页面，文件名叫nvm-setup.exe。如果你访问GitHub下载速度不稳定，也可以用国内镜像站或网盘转存，但务必核对版本号和文件校验信息，防止下载到被篡改的安装包。
双击安装，过程中有两个关键路径需要自定义：
- NVM_HOME：nvm本身和数据存放的目录，默认是C:\Users\用户名\AppData\Roaming\nvm，我建议改成C:\nvm；
- NVM_SYMLINK：Node的软链接目录，也就是在命令行里敲node时实际执行的位置，默认是C:\Program Files\nodejs，我建议改成C:\nvm\nodejs。
装完之后打开一个全新的CMD或PowerShell窗口，输入nvm version，能打印出类似1.1.12的版本号，说明安装成功。如果没有识别，多半是系统PATH里没有写入nvm的路径，需要手动检查环境变量。
2.3 settings.txt关键配置与镜像加速
nvm-windows的核心配置都集中在NVM_HOME目录下的settings.txt文件里。打开之后你会看到两个基础项，root和path，它们分别对应上面的NVM_HOME和NVM_SYMLINK。正常情况下安装程序会自动写入，不需要改。
真正需要手工加的是下面这两行：
node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/加上这两行的原因是：nvm默认从Node官网下载压缩包，在国内经常慢到怀疑人生，甚至直接超时失败。npmmirror是国内使用非常广泛的镜像源，更新频率高，速度和稳定性都有保障。配好之后，nvm install命令的下载速度会快一个数量级，基本能做到秒级下载。
这里还有个小技巧：如果你是在企业内网环境，还可以在settings.txt里同时添加代理配置，比如proxy: http://你的代理地址:端口，方便走了内网代理的机器拉取资源。普通家庭网络用户一般用不到，我就不展开了。
3. nvm核心命令与Node多版本切换实战
3.1 从安装到切换，最常用的命令清单
装好之后，第一步是用nvm list available查看当前可安装的Node版本列表。这个命令会列出远端所有LTS版本和最新版本，信息量比较大，建议配合more命令分页浏览，或者直接看LTS开头的版本行。注意不要执行nvm list，那个列的是本机已安装版本，两者功能完全不同，别混。
安装指定版本的语法是nvm install 版本号，比如：
nvm install 18.20.4 nvm install 20.15.1 nvm install 22.5.1安装完成后，用nvm list查看本机已安装的版本列表，前面带*号的是当前正在使用的版本。切换版本的命令：
nvm use 20.15.1切换成功后命令行会提示Now using node v20.15.1 (64-bit)，这时你输入node -v和npm -v，看到的就是对应版本的输出。
有几个细节值得注意：
- 安装时如果你不指定具体版本号，nvm-windows默认安装的是最新版，但实际工作中我更推荐指定LTS版本，稳定性优先；
- nvm use必须在新的终端窗口里执行，因为PATH环境变量的变更不会自动传递到已经打开的终端，旧窗口继续用旧PATH，这是很多新手感到困惑的点；
- 想要卸载某个版本，用nvm uninstall 版本号，但当前正在使用的版本不能卸载，需要先切到其他版本再执行卸载。
3.2 全局工具统一管理：npm镜像与全局包路径
很多教程讲到nvm install就结束了，其实漏掉了最影响使用体验的全局配置。默认情况下，npm的全局包会安装在当前Node版本目录下的node_modules里，这意味着你每切换一个Node版本，全局安装的包就跟你say goodbye了。比如你刚用npm i -g pnpm装好的包管理器，切到另一个Node版本之后，pnpm命令直接找不到。
这个问题有两种解决思路。
思路一，也是我推荐的做法：把全局包安装目录统一到一个独立路径，比如C:\nvm\node_modules。通过修改npmrc配置文件实现：
npm config set prefix "C:\nvm\node_modules" npm config set cache "C:\nvm\npm-cache"设置完成后，你在任意Node版本下执行npm i -g xxx，装出来的包都在同一个目录里，切换版本之后依然可用，因为我们需要把这个目录加进PATH。怎么加？打开系统环境变量，在Path里新增一条C:\nvm\node_modules，顺序尽量靠前，确保能优先命中。
思路二，简单粗暴：每个Node版本各装一份全局包。坏处很明显，浪费磁盘空间，而且容易忘。比如你在Node 18下装了某个CLI，切到Node 20之后发现命令不存在，容易误判为环境坏了，实际只是没装。
另外，npm镜像也可以在这里统一配置。执行：
npm config set registry https://registry.npmmirror.com之后npm install的下载速度会快很多。这个配置会写入用户级的.npmrc，而不是某个Node版本的目录，所以切换版本也不会丢。我建议把这一步作为nvm装完Node之后的固定动作，写进自己的初始化清单里。
3.3 编辑器与终端里的版本选择
很多朋友装完nvm，打开VS Code继续用，发现node -v还是老版本，以为切换失败。这里有个非常常见的原因：VS Code在启动时读取了系统环境变量，nvm use只是修改了当前进程的PATH，不会影响已经运行的程序。解决方式很简单，重启VS Code，或者在VS Code里新建一个终端再执行nvm use。
还有一个细微的点：如果你使用的是PowerShell，可能需要先执行一次nvm use让当前会话的PATH生效。CMD窗口和PowerShell的行为近似，但PowerShell里的PATH刷新偶尔有延迟，遇到这种情况多执行一次或者直接重开窗口就行。
我个人的习惯是：每个项目在开发前先在集成终端里执行nvm use对应版本，然后npm install，这样可以确保依赖装到正确的Node体系下。有些团队还会用.nvmrc文件配合nvm use命令实现自动化，在项目根目录创建一个.nvmrc，里面写入需要的Node版本号，比如20.15.1，之后每次打开终端执行nvm use，它会自动读取这个文件，省去记版本号的麻烦。
4. 实操中那些绕不开的坑与排查技巧
4.1 常见错误速查表
下面是我在实战中遇到并解决过的典型问题，整理成表格，方便你对号入座。
| 现象 | 原因 | 解决方法 |
|---|---|---|
| nvm install提示下载失败或超时 | 默认下载源在国外，网络不稳定 | 在settings.txt里配置node_mirror和npm_mirror，改用npmmirror镜像 |
| nvm use后node -v仍是旧版本 | 当前终端未刷新PATH，或使用了已打开的进程 | 新开一个CMD/PowerShell窗口再执行；重启编辑器 |
| 安装时提示无法创建符号链接 | 杀毒软件拦截或安装目录权限不足 | 安装阶段暂时退出杀毒软件；用管理员权限运行安装包 |
| 系统找不到nvm命令 | PATH里没有NVM_HOME，或安装路径异常 | 检查环境变量；确认NVM_HOME路径配置正确 |
| npm全局包切换版本后丢失 | 全局包默认安装在当前Node版本目录下 | 用npm config set prefix统一全局包目录 |
| nvm uninstall报错，无法删除 | 当前正在使用该版本 | 先nvm use另一个版本，再执行卸载 |
| 安装的Node版本和期望不一致 | 安装时未指定具体版本，默认装了最新版 | 用nvm list available查看后再手动指定版本 |
4.2 卸载和重装的最佳姿势
如果你之前装过乱七八糟的Node，现在想彻底推倒重来，重点不是卸载，而是清理残留。残留的环境变量和目录比卸载本身更能制造鬼故事。
第一步，把需要保留的全局包列表导出来：
npm list -g --depth=0 > global-packages.txt第二步，依次执行：
- nvm uninstall所有已安装的Node版本；
- 用系统设置卸载nvm-windows；
- 手动删除NVM_HOME目录和NVM_SYMLINK指向的目录；
- 打开“编辑系统环境变量”，把NVM_HOME、NVM_SYMLINK以及手动添加过的npm全局路径全部移除。
第三步，重新安装nvm-windows，装完按前面2.3的内容配置镜像和全局路径，然后重新安装需要的Node版本。
这套流程我实际操作了很多次，最关键是别遗漏环境变量，否则新装完的nvm会跟旧残留起冲突，表现就是nvm命令能执行，但node命令指向的位置不对。
4.3 与pnpm、yarn等工具链的配合
现在前端工程化里pnpm越来越流行，nvm装完之后顺手把pnpm也装上，可以一次性解决包管理器版本混乱的问题。这里有几种装法：
- 在某个Node版本下npm install -g pnpm，然后按3.2的全局目录配置统一管理；
- 直接用官网的安装脚本安装独立的pnpm版本，它自带独立运行时，不依赖系统Node，也支持pnpm env use来管理Node版本。
如果你决定用nvm管理Node，同时又要用pnpm，我建议先用npm把pnpm装到全局目录里，再执行pnpm setup，它会帮你配置好pnpm在shell里的路径，之后pnpm和nvm就可以共处，互不干扰。
yarn也一样，老项目如果锁定yarn 1.x，直接用npm install -g yarn即可；新项目用yarn 2/3的Berry模式，它依赖Node的方式会有所不同，但跟nvm的冲突基本不存在，只要确保你执行yarn时当前nvm切换的版本正确就行。
5. 项目实战：一套完整的多版本工作流
5.1 用.nvmrc统一团队Node版本
前面提过.nvmrc，这里展开说。它本质上就是一个纯文本文件，里面写一个版本号。比如：
20.15.1团队协作时，谁clone代码后执行nvm use，就能快速切到项目要求的Node版本，避免出现“我本地明明是好的”这种因为版本不一致导致的扯皮。nvm-windows的nvm use命令会优先读取当前目录下的.nvmrc文件，所以团队里约定好放这个文件，就等于定了一个自动化的版本切换开关。
我还见过一些团队在.nvmrc里写lts/*或者node这样的半模糊版本，nvm-windows对这种写法的兼容性不好，建议老老实实写具体版本号，避免CI和本地环境行为不一致。
5.2 用批处理脚本解决老项目依赖问题
有一个很经典的情况：老项目的node-sass依赖在Node 16上无法编译，但在Node 14上可以。你可能会想：那我能不能只给这个项目偷偷用Node 14，其他项目都用Node 20？
nvm完全可以做到。你只需要在项目的启动脚本里加上nvm use 14.21.3，或者更稳妥地，在项目目录下创建一个start.bat，里面先nvm use 14.21.3，再启动开发服务。双击这个脚本，它会先切换Node再启动项目，整个过程对团队其他人透明。
如果你用的包管理器是cnpm，这里还有一个坑：cnpm的全局命令默认也装在当前Node版本目录里，切换版本后cnpm会失效。解决方法类似，要么统一全局目录，要么在项目脚本里先nvm use再cnpm install。
5.3 多项目并行时的切换策略
我在实际工作中常常同时开着三个项目：一个老后台Node 14，一个中台Node 18，一个新技术项目Node 22。如果靠记忆去记每个项目用什么版本，很容易切错。
我的做法是给每个项目建一个start.bat，里面固定写法：
@echo off nvm use 18.20.4 npm run dev这样点开就是正确的环境，也不用担心今天切了这个忘了那个。再配合编辑器里的终端配置，直接在项目目录打开新终端，手动执行nvm use，其实也就几秒钟的事情。关键是让它形成肌肉记忆，不要凭感觉。
6. 最后再说几句
写这篇指南之前，我特地又把nvm-windows的安装流程完整走了一遍，发现真正影响体验的往往不是命令本身，而是那些藏在细节里的环境问题：镜像配置、PATH变量、全局包目录、符号链接权限。把这些基础工作做到位，nvm用起来是真的很省心，真正做到一个node -v打天下。
如果你在安装和配置过程中还是遇到问题，先别急着卸载重来，对照4.1的错误速查表逐项排查，90%的情况都能解决。尤其是下载失败和PATH不生效这两个老问题，基本都是配置层面的原因。
最后分享一个小技巧：配置好之后，把常用的LTS版本设为默认，每次新开终端先执行一次nvm use，不用纠结当前项目到底需要哪个版本，效率会高很多。祝大家都能彻底摆脱多版本切换的烦恼，把精力放在真正值得做的事情上。
