1. 为什么要用 nvm 管理 Windows 下的 Node.js
1.1 Node.js 版本混乱带来的痛点
如果你在 Windows 上写过前端或 Node.js 服务端代码，大概率遇到过这种场景：电脑上装了一个 Node.js 18，结果新项目要求 Node 20+，老项目又死活只能跑 Node 16；好不容易卸载旧版本装上新版，另一个项目的依赖又崩了。版本冲突这回事，在 Node.js 生态里非常常见，因为不同框架、不同工具链对 Node.js 的 API 和行为差异很敏感。
以前大家一般怎么做？去 nodejs.org 下载安装包，把旧版卸载，再装新版，然后环境变量里的路径跟着改一遍。一次两次还好，一个月改五六次就非常折磨人。如果同时维护两三个项目，每个项目锁定的 Node 大版本还不一样，那卸载重装这条路基本走不通。还有更隐蔽的问题：很多 Windows 下的原生模块，比如 node-sass、sharp、node-gyp 编译出来的二进制，和 Node.js 版本强相关。你切换 Node 版本之后，全局安装的某些工具或者本地 node_modules 里的原生依赖可能会直接报错，这个时候你特别需要一个能快速切换、随时回退的版本管理方案。
nvm 就是用来解决这个问题的工具。在 Windows 下我们常说的 nvm，其实是 nvm-windows 这个独立项目，它和 macOS/Linux 上常用的 nvm 不是同一个代码库，但核心思路一致：把多个 Node.js 版本同时装在同一台机器上，通过软链接和命令切换当前使用的版本。装完之后，你可以在命令行里只敲一条命令就换一个 Node 版本，不需要卸载、不需要手动改 PATH，项目之间互不干扰。
1.2 nvm 的工作原理和选型理由
要理解 nvm 到底做了什么，需要先了解 Windows 下 Node.js 的安装本质。正常安装 Node.js 时，安装程序会往系统 PATH 里写一个路径，比如C:\Program Files\nodejs，node.exe、npm.cmd 等可执行文件都放在这个目录里。命令行的node -v之所以能用，就是因为系统在这个路径下找到了 node.exe。
nvm-windows 的思路是：所有下载好的 Node.js 版本都放在一个统一的目录里，比如C:\Users\你的用户名\AppData\Roaming\nvm，每个版本一个子文件夹，互不覆盖。然后 nvm 会在 PATH 里维护一个固定的入口目录，默认是C:\Program Files\nodejs，这个目录本身不是一个真实文件夹，而是一个指向当前激活版本的符号链接。当你执行nvm use 18.20.4，nvm 就把这个符号链接重新指向18.20.4那个版本的目录；执行nvm use 22.11.0，符号链接又指向22.11.0。系统 PATH 从头到尾不用改，因为入口路径永远是同一个。
理解了这一点，你就明白为什么安装 nvm 后最好把原先独立安装的 Node.js 卸载掉，或者至少把它从 PATH 里移除。如果两个路径同时存在，命令行解析 node 命令时先命中了旧路径，你会发现不管怎么nvm use，node -v显示的版本还是老版本。我自己第一次装 nvm 时就踩过这个坑，折腾了半小时，最后where node一看，路径根本不在 nvm 的符号链接目录里。
至于为什么推荐用 nvm 而不是手动维护多个版本的压缩包，简单说就是省心：下载自动、版本列表自动、切换自动、卸载自动。你不需要记住每个版本的下载地址，不需要关心压缩包解压到哪，也不用担心以前装的版本残留一堆 PATH 垃圾。这些自动化能力在团队协作时尤其有用——新人来了照着文档敲三条命令，开发环境就齐了。
2. 安装 nvm-windows 前的环境准备
2.1 卸载旧 Node.js 和清理 PATH
安装 nvm 之前，我建议先看一眼当前电脑上的 Node.js 是从哪来的。你可以在命令行执行：
where node如果输出里有多个路径，说明曾经手动配置过多个 Node 环境，建议把所有非 nvm 管理的路径全部清理掉。正常的 Windows 引导安装，路径一般就一个C:\Program Files\nodejs\node.exe。打开“设置 -> 应用 -> 已安装的应用”，找到 Node.js 并卸载，然后再检查where node，确保命令提示符里已经找不到 node 了。
接着检查环境变量里的 PATH。按 Win + R 输入sysdm.cpl，切到“高级 -> 环境变量”，在用户变量和系统变量里都翻一下，凡是包含 node、npm、yarn、pnpm 全局安装路径的条目，确认来源后删除。这里要特别注意 npm 全局包安装目录，很多老教程让大家把 npm 的 prefix 改成自定义文件夹，比如D:\npm\node_modules，然后手动加到 PATH。这类路径和 nvm 的符号链接机制容易打架，建议先清理干净，等 nvm 装好再重新规划全局安装位置。
卸载完成后，最好重启一次终端，甚至重启电脑。Windows 的环境变量缓存有时候很顽固，旧进程还占着旧 PATH，你直接跑node -v可能还会蹦出旧版本。我遇到过卸载 Node 后系统 PATH 里还残留一个空目录，虽然没实际文件，但where node还是会报错提示找不到，折腾半天才发现是 PATH 里那个幽灵路径在捣乱。
2.2 下载 nvm-setup.exe 并正确安装
nvm-windows 的发布页面在 GitHub 上的 coreybutler/nvm-windows，进入 Releases 页面下载最新版的nvm-setup.exe。不要下载带-noinstall字样的压缩包，那是给喜欢手动配环境变量的老手用的。新手直接装 exe，安装器会把环境变量、目录结构、符号链接一次性配好。
安装时有几个细节需要注意。
第一，安装包建议右键“以管理员身份运行”。原因前面说过，nvm 需要在C:\Program Files\nodejs创建符号链接，普通用户权限在一些 Windows 配置下会失败。如果安装完nvm use总是报创建软链接失败，基本就是权限问题。
第二，安装目录可以改。我习惯把 nvm 本体装到D:\nvm这种非系统盘，因为 Node 版本会越装越多，每个版本一百多 MB，攒十个版本就是 1GB 多，放 C 盘比较占空间。安装器会让你选两个路径，一个是 nvm 版本库目录，一个是 Node.js 符号链接目录。符号链接目录保持默认的C:\Program Files\nodejs即可，这个路径只是入口，不是真实文件，不占空间。
第三，整个安装路径里不要出现中文或空格。虽然新版 nvm-windows 对空格的处理好了很多，但 Node 生态里的很多工具还是对路径比较敏感，用中文用户名或者带空格的目录容易出现各种诡异问题。如果 Windows 用户名本身是中文，安装路径默认就会带着中文，这种情况建议把安装目录手动改成D:\nvm这种纯英文路径。
安装完成后，重新打开一个终端，执行：
nvm version能看到版本号就说明装好了。如果提示找不到 nvm，检查用户变量里有没有NVM_HOME和NVM_SYMLINK两个变量，以及 PATH 里有没有%NVM_HOME%。安装器一般会自动配好，但手动改过 PATH 的机器可能会漏。
2.3 检查 NVM_HOME 和 NVM_SYMLINK 配置
安装器配置了两类关键信息：一是 nvm 自身程序的路径，二是 Node.js 入口符号链接的路径。你可以打开环境变量编辑器看一眼，用户变量里通常会有：
NVM_HOME = C:\Users\你的用户名\AppData\Roaming\nvm NVM_SYMLINK = C:\Program Files\nodejs同时 PATH 里应该有%NVM_HOME%或完整的 nvm 目录路径。这里有一个容易被忽略的点：NVM_SYMLINK表示的目录在 nvm 安装时可能还不存在，等第一次nvm use成功才会生成符号链接。如果之后你手动删过C:\Program Files\nodejs，nvm 使用时会重新创建，不用惊慌。
如果你用的是绿色版或者手动配置环境变量，还需要确保 nvm 目录下有一个settings.txt文件。正常安装器会自动生成，它的作用相当于 nvm 的总配置中心。我建议装完后顺手打开这个文件看一眼，内容类似：
root: C:\Users\你的用户名\AppData\Roaming\nvm path: C:\Program Files\nodejs arch: 64 proxy: none node_mirror: https://nodejs.org/dist/ npm_mirror: https://github.com/npm/cli/archive/root是版本库存放位置，path是符号链接入口，arch是默认架构。如果你不是管理员，或者想把入口目录放到一个用户有权限的目录，比如D:\nodejs，可以改path，同时把环境变量NVM_SYMLINK一起改掉，让两者保持一致。不过对大多数人来说，保持默认就够了。
3. nvm 核心命令与 Node.js 版本安装
3.1 常用命令速查
nvm-windows 的命令不多，先用一张表把最常用的列出来，后面再展开讲具体场景。
| 命令 | 作用 |
|---|---|
nvm list available | 列出可远程下载的 Node.js 版本 |
nvm list | 列出本地已安装的版本，当前版本带* |
nvm install <version> | 安装指定版本，例如nvm install 18.20.4 |
nvm install latest | 安装最新版本 |
nvm install lts | 安装最新 LTS 版本 |
nvm use <version> | 切换当前使用的版本 |
nvm uninstall <version> | 卸载指定版本 |
nvm on/nvm off | 启用 / 停用 nvm 的版本管理 |
nvm arch | 查看或设置架构，32 位或 64 位 |
nvm root | 显示 nvm 版本库目录 |
命令看起来很简单，但有几个细节会影响实际体验。第一，nvm install后面可以直接写大版本号，比如nvm install 18，nvm 会帮你解析成 18.x.x 的最新版。不过这个行为依赖版本列表接口的返回顺序，有时会装到预发布版本，建议在关键项目里还是写完整版本号，比如nvm install 20.11.1。
第二，nvm use切换成功后会创建符号链接，所以执行完最好验证一下：
node -v npm -v如果输出不是你想要的版本，别急，先关掉当前终端重新开一个。Windows 终端对 PATH 的缓存策略很迷，新开的命令行窗口才会重新读取环境变量。
第三，nvm install默认安装 64 位版本。如果你有特殊需求，可以执行：
nvm install 18.20.4 32根据当前项目所需的 Node 架构来选择。大多数前端项目用 64 位就足够，除非你在维护一个老旧的 32 位原生模块依赖工程。
3.2 使用国内镜像加速下载 Node.js
nvm install默认从https://nodejs.org/dist/下载，国内网络环境下速度时好时坏，几十 MB 的包下载半天很常见。解决办法是给 nvm 配置镜像源。
打开 nvm 安装目录下的settings.txt，把node_mirror改成：
node_mirror: https://npmmirror.com/mirrors/node/意思是从 npmmirror 的 Node.js 镜像目录下载压缩包。这里要注意，新版 npmmirror 的地址是https://npmmirror.com/mirrors/node/，不带dist后缀。有些老教程写的是https://npm.taobao.org/mirrors/node/，那个域名现在已经不建议用了。
改完保存，再执行：
nvm install 18.20.4下载速度会明显提升。如果你不想改文件，也可以直接用命令设置：
nvm node_mirror https://npmmirror.com/mirrors/node/这条命令会把值写进 settings.txt，效果一样。npm_mirror同理，但实际安装时 npm 通常随 Node 压缩包一起提供，所以我一般只改node_mirror。
有个坑和镜像有关：如果某个版本在官方源刚发布，但镜像还没同步，nvm install会报错提示版本不可用。常见提示是：
Error installing 24.20.0: Node.js v24.20.0 is not yet released or is not available.这有两种可能，一是版本号打错了，二是镜像不同步。可以先执行nvm list available看看期望的版本在不在列表里，如果列表里已经有这个版本但还是装不上，把settings.txt里的node_mirror改回官方https://nodejs.org/dist/再试一次，一般就能解决。
3.3 多版本切换与回退操作
本地同时安装多个版本后，切换是一件非常轻松的事。比如我电脑上现在有 Node 16 和 Node 20，分别用于两个不同时代的项目。
nvm list输出类似：
* 20.11.1 (Currently using 64-bit executable) 16.20.2带*的是当前激活版本。想切到 16，直接执行：
nvm use 16.20.2再执行：
node -v就会显示v16.20.2。如果提示“exit code 1”或者“cannot create symbolic link”，大概率是权限问题，关掉当前终端，换管理员身份重新打开命令行再试。
还有一个容易忽略的细节：nvm use切换的是全局默认版本，不是说在某个项目目录下自动切版本。它不会根据你当前进入哪个项目自动选择 Node 版本。如果你想做到“进入项目自动切版本”，需要配合 IDE 或终端插件的钩子来做。不过对于绝大多数场景，手动切一条命令已经比卸载重装高效太多了。
如果你彻底不用 nvm 了，可以执行nvm off停用版本管理，但符号链接目录可能还会残留。想要干净卸载，先执行nvm off，再用安装器自带的卸载功能，或者手动删除 nvm 目录和符号链接目录，同时清理环境变量。不要直接删除C:\Program Files\nodejs，那是个链接指向的入口，删之前确定 nvm 已经停用。
4. 全局配置 npm：镜像源、缓存和全局安装目录
4.1 为什么需要单独配置 npm
nvm 解决的是 Node.js 运行时版本的问题，但 npm 自身也有很多需要配置的地方。每次nvm install后，npm 都会随版本一起装好，不同 Node 版本对应的 npm 版本也不同。你的 npm 配置存放在用户目录下的.npmrc文件里，和 Node 版本无关，所以哪怕切了 Node 版本，npm 的 registry、全局安装路径等配置依然生效。
日常开发里最常见的两个痛点是：默认 registry 在国内下载依赖太慢，以及全局安装的工具包位置不明确。npm 官方源 download 速度不稳定，设置国内镜像后能明显改善npm install的体验。全局安装路径则涉及你执行命令时能不能找到vue、nest、pnpm等工具，路径配置错了，会看到“xxx 不是内部或外部命令”的报错。
4.2 配置 registry、cache 和全局目录
命令行下依次执行：
npm config set registry https://registry.npmmirror.com/ npm config set cache "D:\npm_cache"第一条把依赖下载源切到 npmmirror；第二条把 npm 的缓存目录挪到非系统盘，避免 C 盘被塞爆。npm 默认缓存路径在C:\Users\你的用户名\AppData\Local\npm-cache，用久了之后体积非常可观，几十 GB 都有可能，尤其是经常创建新项目、反复安装依赖的开发者。
至于全局安装目录，nvm 环境下我建议保持默认，不要乱设prefix。因为 nvm 切换 Node 版本后，node、npm 本身path是靠符号链接实现的，全局包默认安装到C:\Users\你的用户名\AppData\Roaming\npm，这个路径独立于每个 Node 版本，切换版本后工具命令仍然能找到，比较稳定。如果你按照某些老教程把prefix改成某个 Node 版本目录下的子文件夹，切到另一个版本后那些全局工具可能瞬间消失，因为它们挂在旧版本的目录里。
查看当前全局根目录和缓存路径，可以用：
npm root -g npm config get cache npm config get prefix重点确认一下prefix指向的路径是否和 nvm 管理的版本目录有关。如果无关，可以不动；如果有关，执行：
npm config set prefix "C:\Users\你的用户名\AppData\Roaming\npm"然后把这个目录加进系统 PATH。nvm 安装器一般不会自动加这个路径，但很多全局命令行工具靠它才能被直接调用。
4.3 nvm 环境下安装全局工具的注意事项
用 npm 安装全局工具时，原生模块依赖比纯 JavaScript 包更容易踩坑。比如安装node-gyp、sharp这类模块时，它们包含 C++ 编译产物，和 Node.js 版本、ABI 版本绑定。你使用npm install -g时装在 Node 20 下，切换到 Node 16 后，即使命令能找到这个包，运行也可能直接报错。
如果是带 CLI 的纯 JS 工具，比如pnpm、vue-cli、nest-cli，切换 Node 版本影响不大。但原生模块工具，我一般建议按项目局部安装，或者切完 Node 版本后重新安装一次全局包。这条经验在 Windows 上特别明显，因为官方预编译二进制不一定齐全，有时会走到本地编译，一编译就容易出现各种编译环境错误。
还有一个小细节：npm 全局包的缓存在.npmrc里，和 nvm 的版本库目录是两套东西。切换 Node 版本时，npm 全局缓存不会跟着丢失，但你本地 node_modules 里的依赖可能需要删除重装。尤其是从大版本切换到大版本，比如 Node 14 切到 Node 18，很多包的 lockfile 会被改掉，最好直接npm ci而不是npm install。npm ci会依据 lockfile 精确安装版本，避免升级依赖带来的意外。
5. 实战记录：从零搭建一个可切换的多版本环境
5.1 完整操作流程示例
假设你的电脑是一台全新的 Windows 11，64 位系统，现在要装一个能同时跑 Node 16 老项目和 Node 20 新项目的环境。完整流程可以这样走。
第一步，下载并安装 nvm-windows。以管理员身份运行nvm-setup.exe，安装目录选D:\nvm，符号链接目录保持默认。安装完打开新的 PowerShell 或 CMD，执行nvm version验证。
第二步，修改D:\nvm\settings.txt，把node_mirror改成https://npmmirror.com/mirrors/node/。如果你是新电脑，也可以不改，直接官方源下载；看自己网络情况决定。
第三步，安装两个 Node 版本：
nvm install 16.20.2 nvm install 20.11.1每个版本安装后，nvm 都会自动给你准备好对应的 npm。安装完成后，用nvm list可以看到两个版本都在。这时先设一个默认版本：
nvm use 20.11.1 node -v npm -v如果输出正常，说明符号链接已经建立，后续打开的终端默认走 Node 20。
第四步，配置 npm 镜像和缓存：
npm config set registry https://registry.npmmirror.com/ npm config set cache "D:\npm_cache"再顺手装一个现在常用的全局工具，比如 pnpm：
npm install -g pnpm然后开新终端，执行pnpm -v，能正常输出版本号就说明全局路径没问题。
第五步，模拟切换到老项目。进入一个要求 Node 16 的项目目录，执行：
nvm use 16.20.2 node -v npm ci这时候 node_modules 会基于 Node 16 重新安装，项目就能正常启动了。等你切回 Node 20 的新项目，再nvm use 20.11.1就行。整个过程不需要卸载任何东西。
5.2 用 .nvmrc 锁定项目 Node 版本
团队协作时，光靠口头叮嘱“这个项目要用 Node 16”很容易出错。新来的同事可能电脑上默认是 Node 20，跑起来一堆报错。建议每个项目根目录下放一个.nvmrc文件，内容就一行：
16.20.2这个文件在 macOS/Linux 的 nvm 中有专门的支持，进入目录后执行nvm use会自动读取。Windows 的 nvm-windows 对.nvmrc的支持没有 Linux 版那么完善，但你可以手动用一行命令读取：
nvm use (Get-Content .nvmrc)这是 PowerShell 的写法，CMD 下可以写：
for /f %i in (.nvmrc) do nvm use %i虽然没有那么“无感”，但至少比翻聊天记录找版本号靠谱。我更推荐的做法是，在项目的 README 里写清楚 Node 主版本，同时配合.nvmrc双保险。
此外，前端工程里通常还会在package.json的engines字段声明 Node 版本范围：
{ "engines": { "node": ">=16.20.0 <17" } }加上engine-strict=true可以让 npm 在版本不匹配时直接报错。这个字段本身不能阻止你跑错版本，但至少能让问题暴露得更早。
5.3 处理“切换版本后 npm 不是同一个”的细节
有一个现象很多新手会困惑：nvm use 16.20.2之后node -v变成 16 了，但npm -v看起来还是旧版本。这个情况一般是终端缓存导致的，开一个新终端再看。如果新终端里依然不对，检查where npm，看看 npm.cmd 的实际路径是不是还在旧 Node 版本的目录下。
nvm 的符号链接指向的是目录本身，node.exe 和 npm.cmd 都在同一个版本目录下。正常切换后where npm应该指向C:\Program Files\nodejs\npm.cmd或 nvm 当前版本目录下的 npm.cmd。如果指向的是C:\Users\username\AppData\Roaming\npm，那可能是 npm 全局 bin 目录里的 npm 同名词柄，属于正常现象，不代表版本没切过来。判断依据始终以node -v和npm -v的实际输出为准。
如果你发现 npm 版本和 Node 版本不匹配，比如 Node 20 配了一个旧 npm，可以手动升级 npm：
npm install -g npm@latest这会装到 npm 的全局目录里，不冲突。但要注意，用它全局覆盖后，当前 Node 版本对应的 npm 可能和预期版本有差异，这是 npm 自身的机制，别慌。
6. 高频问题与排错经验
6.1 nvm use 报 exit code 1 或无法创建符号链接
这是 nvm-windows 在 Windows 上最经典的问题。nvm use本身可能执行成功，但紧接着报错exit code 1，或者提示创建符号链接失败。原因基本只有一个：没有管理员权限。符号链接C:\Program Files\nodejs创建在 Program Files 目录下，普通用户无权操作。
解决办法很简单：关掉当前终端，右键“以管理员身份运行”打开 CMD 或 PowerShell，再执行：
nvm use 20.11.1如果已经用管理员身份运行还报错，检查 Windows 的开发者模式是否打开。进入“设置 -> 安全和更新 -> 开发者选项”，开启“开发人员模式”。虽然不是严格必须，但很多时候能解决符号链接权限的边界问题。
还有一种情况是杀毒软件或安全策略拦截了符号链接创建。这种比较少见，如果你用的是企业定制的 Windows，安全策略可能比较严格，可以考虑把path改成一个用户目录下的路径，比如C:\Users\你的用户名\nodejs，同时改环境变量NVM_SYMLINK指向相同路径，权限要求会低很多。
6.2 下载 Node 版本时报 404 或版本不可用
nvm install报 404，或者提示“is not yet released or is not available”，常见原因有三个。
第一，版本号写错了。下载地址是根据版本号拼出来的，nvm install 18.204这种明显不可能存在。用nvm list available看准确的版本列表再装。
第二，镜像源没同步。官方源刚发版的几个小时内，国内镜像未必同步，尤其是新版 LTS 刚发布那几天。临时切回官方源是个办法。
第三，Node 版本比较老，目录里没有对应位的二进制。比如nvm install 0.12.18这种非常老的版本，可能只有 32 位包，默认 64 位架构下载时就会 404。这时可以显式指定 32 位：
nvm install 0.12.18 32 nvm arch 32nvm 在下载时会按照 URL 规则拼地址，空指针、路径拼错都会把错误引到 404 上。遇到这类问题别急着怀疑网络，先看提示是全的一行还是包含具体 URL，顺着 URL 手动访问一次往往能定位是源的问题还是版本号的问题。
6.3 切换版本后全局命令找不到或全局包消失
出现这个问题的直接原因是全局包的安装目录不在 PATH 里，或者prefix配置指向了旧版本目录。先执行：
npm config get prefix npm prefix -g正常情况下prefix -g输出应该是一个独立于 Node 版本的全局目录。如果你把prefix设置成了版本目录下的路径，比如C:\Users\你的用户名\AppData\Roaming\nvm\v16.20.2，那切到 Node 20 后，命令行自然找不到之前装在 Node 16 全局目录里的工具。
解决方式是重置 prefix：
npm config delete prefix npm config set prefix "C:\Users\你的用户名\AppData\Roaming\npm"然后把C:\Users\你的用户名\AppData\Roaming\npm加进用户 PATH。记得新开终端才能生效。
全局命令找不到还有一种可能是原来用的不是 npm 全局安装，而是某个安装器自动生成的可执行文件路径，路径里带了旧 Node 的版本目录。这种情况建议把依赖重装一遍，而不是手动去改路径，手动改路径容易留下更多隐患。
6.4 npm install 报错和 node_modules 需要清理
切换 Node 大版本后，项目里的 node_modules 经常要重新安装，尤其是 lockfile 还是旧版本生成的情况下。跑npm install可能报各种奇怪的错，比如ERR! npm ERESOLVE、Module version mismatch、NODE_MODULE_VERSION等。NODE_MODULE_VERSION 错误是原生模块的经典报错，本质是模块编译时用的 Node ABI 版本和当前运行时不匹配。
处理办法不复杂，先删除 node_modules 和一个 lockfile：
rm -rf node_modules package-lock.json npm cache clean --force npm ci如果项目里有yarn.lock或pnpm-lock.yaml，用对应的包管理器重新安装。对于原生模块，优先找有没有预编译二进制，比如node-sass这种老模块，可以尝试改用sass或dart-sass替代。实在不行就把 Node 版本切回模块编译时用的那个版本，不要硬扛。
我个人的习惯是：每个 Node 大版本对应一套独立的全局包缓存和 node_modules，切换大版本后不偷懒，老老实实重装依赖。虽然耗时，但能避免很多无法解释的诡异问题。
7. 几点长期使用的心得
7.1 把“默认版本”固定在 LTS 上
nvm 不像一些版本管理工具那样有什么默认版本配置项，它记住的是最后一次nvm use的版本。新终端打开的 node 版本，就是你最后切换的那个。这个设计够用，但有个风险：某次临时切到旧版本调试，之后忘了切回来，第二天新开终端用的还是旧版本，项目跑起来才发现。
所以我现在的习惯是：每次用完后，只要不是专门在调旧项目，就手动切回一个长期稳定版本：
nvm use 20.11.1如果团队有统一技术栈，建议在开发环境初始化文档里写明“安装完成后执行 nvm use xx 切换到指定版本”，避免有人卡在版本不对的怪问题上。版本管理工具存在的前提就是降低人为错误，但前提是你得把版本切换当作日常流程的一部分，而不是“装完就完事”。
7.2 定期清理本地不用的旧版本
nvm 装版本非常方便，这导致另一个问题：你可能会把一堆老版本堆在硬盘里，从不清理。实际上很多老版本完全派不上用场，只是当时为了排查某个依赖问题临时装的。
我建议先执行：
nvm list看看本地到底装了哪些版本。连续三个月没用到过的版本，直接：
nvm uninstall 14.21.3释放的不仅是磁盘空间，还能减少系统 PATH 附近符号链接的复杂度。当然，如果某个老项目还在周期性地维护，即使不常跑，也建议留着对应的 Node 版本，别为了一点磁盘空间破坏已有项目的可复现性。清理动作之前先确认是否有项目 lockfile 或脚本写死了这个版本。
7.3 善用其他工具与 nvm 配合
nvm 管理的是 Node.js 运行时，但前端工程里往往还有 pnpm、yarn、fnm、volta 这类工具，很多人会纠结它们之间是什么关系。我的看法是：nvm 管版本，pnpm/yarn 管包依赖，两者定位不同，完全可以搭配使用。
对于新项目，我比较推荐 Node 版本统一用 nvm，包管理器统一用 pnpm。npm 会随 Node 版本自动切换，pnpm 是全局安装的，切 Node 版本不会影响。qian端工程在项目根目录写好 packageManager 字段，或者用corepack enable管理。这样 nvm 负责运行时，corepack/pnpm 负责依赖锁版本，各司其职。
另外，如果你切换 Node 版本比较频繁，可以考虑给终端窗口安装一个显示当前 Node 版本的提示插件，比如 PowerShell 的 oh-my-posh，或者直接用命令行快速 echo：
echo "当前版本 $(node -v)"这个提示可以在很大程度避免“切了版本但忘了切回来”的尴尬。我在实际开发中踩过几次坑之后，已经养成了每次建新终端先node -v的习惯，成本很低，但能省下大量排查时间。
回到前面的问题，Windows 下用 nvm 安装和管理 Node.js，本质上不是装一个软件，而是建立一套“多版本共存、按需切换、随时可回退”的开发环境管理思路。把它配置好，之后不管接老项目还是新项目，心态都会稳很多。希望这份指南能帮你少走一些弯路。
