最近一段时间，我在好几个技术群里都看到有人反复搜同一个问题——“nvm系统盘路径”。顺着这个词翻下去，后面还跟着一串相关搜索：“nvm could not be found or does not exist. exiting. no installations recognized”、“nvm安装及全局配置node”、“windows如何安装nvm的v0.40.8版本”。说实话，大家在意的根本不是“nvm”这三个字母本身，而是装完之后一堆说不清的问题：装到哪个盘、全局包装到哪去了、为什么切版本老报错、为什么明明安装了版本却不识别。这篇文章我不打算只给一个“装C盘还是D盘”的结论，而是把 nvm 在 Windows 上的安装路径、目录结构、全局配置、报错排查一条线讲透，保证你照着操作能真正搞懂，而不是稀里糊涂装完继续踩坑。
先说一句题外话：本文说的 nvm 是 Node Version Manager（Node 版本管理工具），面向前端/Node 开发场景。汽车电子里也有个 NvM（NVRAM Manager），那是 AUTOSAR 的非易失存储器管理模块，跟这个完全是两码事。搜索关键词撞车，先在这里拆清楚。
1. “系统盘路径”这个搜索词背后的真实场景：nvm到底该装在哪
1.1 默认路径是C盘，但C盘不一定是最优解
nvm-windows 的官方安装包 nvm-setup.exe 装完以后，默认目录是：
C:\Users\你的用户名\AppData\Roaming\nvm同时还会创建一个 nodejs 软链接目录，默认在：
C:\Program Files\nodejs这两个路径就是很多人搜“系统盘路径”时最先遇到的东西——他们认为 nvm 就是装在系统盘 C 盘。实际上没错，默认确实在 C 盘，但问题也恰恰出在这两个默认路径上。
AppData\Roaming 路径很深，中间还夹着用户名。如果用户名是中文或者带空格（比如 C:\Users\张三\），有些老版本的工具、脚本在解析路径时就会出幺蛾子。而 C:\Program Files\nodejs 这个路径中间也带空格，CMD 里一旦有人手写路径忘了加引号，后面 nvm use、npm 命令全都会连锁报错。
所以社区里绝大多数安装教程会建议你安装的时候手动指定两个更“干净”的路径——
nvm 安装目录（工具本体） -> C:\nvm nodejs 软链接目录（对外暴露） -> C:\nodejs路径短、无空格、无中文，后续排查问题会省掉很多不必要的干扰。我自己的机器上一开始就是默认安装，后来为了截图写教程重装过一次，改成 C:\nvm 和 C:\nodejs 之后，很多奇怪的问题再也没出现过。
1.2 系统盘、C盘与D盘：环境变量才是真正的主权
很多人纠结“系统盘路径”到底是指 C 盘还是泛指所有硬盘分区。这里要纠正一个概念：Windows 里的“系统盘”通常特指安装操作系统的那个分区，也就是 C 盘。但 nvm 相关搜索里出现“系统盘路径”，其实是用户想表达“nvm 装在哪个盘、哪个目录，才算规范”。
我见过两类典型用户：
- 一类是 C 盘空间紧张，想把 nvm 和 node 都放到 D 盘，但又怕改了路径之后 nvm 不工作；
- 另一类是刚买电脑不久，觉得软件就应该装在 C 盘默认路径，但又发现默认路径太深，心里不踏实。
这两种需求都不难解决。nvm 装到哪个盘，本质上只取决于两个环境变量：
| 环境变量 | 作用 | 安装程序默认值 |
|---|---|---|
| NVM_HOME | nvm 工具本体所在目录 | %APPDATA%\nvm |
| NVM_SYMLINK | nodejs 对外链接目录 | C:\Program Files\nodejs |
只要这两个变量指向正确，nvm 装在 C 盘还是 D 盘完全无所谓。如果你决定装到 D 盘，安装时把目录改成 D:\nvm 即可，安装程序会自动把 NVM_HOME 指过去。如果你希望那层“node 命令对外接口”也放到 D 盘，第二步设置 symlink 时改成 D:\nodejs 就行，不用为了“C 盘执念”委屈自己。
我个人建议的判断标准只有一个：如果你的 C 盘剩余空间低于 30GB，或者你重装系统很频繁，就把 nvm 放到 D 盘。版本目录本身不大，一个 node 版本解压后约 100MB 左右，装四五个版本也就半 GB，但它产生的全局缓存（npm cache）会随着时间增长到几个 GB，这部分才真正吃空间。
1.3 先分清你用的是哪个nvm：nvm-windows与原版nvm的差异
搜索“v0.40.8版本”的时候，很容易被带偏。这里必须做一个版本澄清：
- 适用于 Windows 的 nvm 其实叫nvm-windows，是独立开发的 .exe 程序，不是 Linux/macOS 上那个 shell 脚本版 nvm。它的官方 release 版本号目前是1.x 系列（比如 1.1.11、1.1.12）。
- 0.40.8 这个版本号是原版 nvm（基于 shell 脚本，主要跑在 Mac/Linux）的版本号，或者是一些第三方教程对 Windows 版 nvm 的误写。
如果你在 Windows 上搜索”v0.40.8 安装包”，下载到的很可能不是 nvm-windows 官方产物。安全第一，不要从不明站点下载 exe。正经做法是去 nvm-windows 的官方 GitHub Releases 页面，下载 nvm-setup.exe，你也会看到 Windows 版的版本号是 1.x，而不是 0.40.x。
2. nvm-windows安装前的路径规划：NVM_HOME与NVM_SYMLINK一次配好
2.1 下载与安装流程，包含最容易忽略的一步
安装 nvm-windows 之前，如果你电脑上已经用官方安装包单独装过 Node.js，建议先把它卸载掉。原因很简单：nvm 要靠 NVM_SYMLINK 那个目录对接系统 PATH，如果原本的 node 已经存在，两个 node 会打架，输入 node -v 你根本无法确定返回的是哪一份。
下载 nvm-setup.exe 之后，双击运行，安装过程只需要注意两个界面：
- Select Destination Location：选择 nvm 的安装位置，我推荐 C:\nvm 或 D:\nvm。
- Set Node.js Symlink：设置 node 命令对外暴露的目录，我推荐 C:\nodejs 或 D:\nodejs。
第二个界面很多人会直接一路 Next 跳过。这一步不是随便填着玩的，它写进的是一个叫 NVM_SYMLINK 的环境变量。后续你每次 nvm use 切换版本，系统 PATH 里一直指向的都是这个目录，而不是具体版本目录。相当于这个目录是个中转站，nvm 在里面换内容，外部程序无感知。
装完之后打开系统属性 -> 环境变量，你会看到安装程序已经帮你写好了下面这几项：
NVM_HOME = C:\nvm（或你指定的目录） NVM_SYMLINK = C:\nodejs（或你指定的目录） PATH 追加项 = %NVM_HOME%;%NVM_SYMLINK%如果你发现自己环境变量里没有 NVM_SYMLINK，只有 NVM_HOME，说明安装时第二步被跳过了或者安装包太老。可以手工补：
NVM_SYMLINK = C:\nodejs然后把 %NVM_SYMLINK% 加到 PATH 里，位置放到所有 Node 相关路径之前。
2.2 安装后的第一波验证：不要急着装高版本
装完 nvm 之后别急着 nvm install 20，先开一个全新的CMD 窗口（老窗口读不到新环境变量），执行：
nvm list正常情况下输出是空列表或提示没有安装版本。接着：
nvm install 18.20.4 nvm use 18.20.4 node -v能打印出 v18.20.4，说明整条链路是通的。如果你的输出变成了 “nvm could not be found or does not exist”，先别重装，直接跳到第五节看完整排查链路。
另外，安装 nvm-windows 之前最好先把系统里残留的 Node 全局目录清干净。旧版 Node 默认会把全局包放在C:\Users\用户名\AppData\Roaming\npm，PATH 里通常也配着这个路径。nvm 装好之后，这条旧路径如果不删，npm -g装出来的命令可能会被旧路径里的同名命令“截胡”——系统会优先启动 PATH 里排在前面的那个。
2.3 为什么安装路径里尽量不要出现空格和中文
这点我在前面提过，但值得展开说。Windows 的 CMD 对空格的处理比 PowerShell 粗暴得多，很多脚本直接用 node 路径拼接字符串。一旦路径里有空格，你的命令就变成：
C:\Program Files\nodejs\node.exe ...如果没有额外加引号，系统会把 C:\Program 当成一条命令，然后报“不是内部或外部命令”。nvm 安装完之后，一些全局工具（比如 TypeScript、Vite、Electron 相关脚本）生成的 .cmd 批处理文件里会写死 node 的路径，这些文件未必都做了良好的引用处理，路径越简单越安全。
中文路径的问题更直接：某些老工具根本不做 UTF-8 编码转换，把中文路径写到缓存索引里时直接乱码，后续启动直接找不到文件。
所以我的路径规划建议是：
nvm 工具本体： D:\nvm nodejs 链接： D:\nodejs 全局包位置： D:\nodejs\npm-global npm 缓存： D:\nodejs\npm-cache这套方案的核心思想是：所有和 node 相关的东西都在同一个大盘下，结构一眼能看明白，C 盘也不会被慢慢蚕食。
3. 目录结构全拆解：看清nvm与nodejs那个“软链接”在干嘛
3.1 打开C:\nvm你会看到什么
装完几个版本之后，打开 nvm 安装目录，你会看到一堆以 v 开头的文件夹：
C:\nvm ├── v16.20.2 ├── v18.20.4 ├── v20.11.1 ├── settings.txt └── ...（临时文件和下载缓存等）每个 v 开头文件夹里面都是一套完整的 Node 运行时，有 node.exe、npm.cmd、node_modules 这些。
这时候你再看 C:\nodejs，会发现它看起来也是个文件夹，里面也有 node.exe，但这是 nvm 从某个版本目录“链接”过来的。Windows 文件系统里这叫 junction（目录联接），长得像个文件夹，实际上是个指针。CMD 里执行：
dir C:\nodejs会看到里面有 node.exe，继续用 PowerShell 查看链接指向：
Get-Item C:\nodejs | Select-Object LinkType, Target你就能看到它当前指向的是 C:\nvm\v18.20.4 这样的物理目录。
3.2 nvm use 到底做了什么
搞清楚这个机制，你对 nvm 的理解就算入门了。每次执行：
nvm use 18.20.4nvm 做的事情本质上是：把 C:\nodejs 这个目录联接，重新指向 C:\nvm\v18.20.4。
PATH 环境变量从头到尾都没变过——里面始终只有 C:\nodejs。你敲 node 的时候，系统找到 C:\nodejs\node.exe，然后顺着目录联接进入真正的版本文件夹。nvm 切换版本，换的就是这根“指针”的指向。
这就是为什么 nvm-windows 必须在 Windows 上依赖 junction/symlink 机制，也解释了为什么安装时必须指定一个专门的 nodejs 链接目录：如果没有这个目录，nvm 就没法在不改 PATH 的情况下完成版本切换。
用一个生活例子来记：C:\nodejs 是门牌号，C:\nvm 下的 v18.20.4 这些文件夹是房子。nvm use 就是搬家——门牌号不变，门后通向的房子换了。外部送信的人（node 命令）只要认门牌号就行，不需要知道你今天住哪套房。
3.3 全局包的真实位置：一个常见的误解
很多新手以为 npm install -g 装出来的包会出现在 C:\nodejs 目录下。其实不完全是。
默认情况下，npm 的全局路径是“当前 node.exe 物理路径”下的 node_modules 目录。也就是说，当你当前使用的是 v18.20.4 时，执行：
npm install -g yarn实际会把 yarn 装到：
C:\nvm\v18.20.4\node_modules而不是 C:\nodejs\node_modules（因为 C:\nodejs 只是链接门面）。
这就带来了一个很多人没反应过来的后果：当你用 nvm 切换版本后，原来版本的全局包并不会带到新版本里。比如你在 v18.20.4 下装了 yarn，切到 v20.11.1 之后敲 yarn，系统找不到命令。
这个行为其实是 nvm 的安全设计——避免不同版本之间因为全局包不兼容而互相污染。但代价是，你每换一个新版本，就要重新安装该版本所需的那几个全局工具。想要彻底摆脱“每个版本重复装全局包”的烦恼，就需要用第 4 章的方案，把全局包固定到一个不随版本变化的目录。
3.4 验证思路：一条命令看清当前物理路径
排查问题前，先确认自己的 node 到底指向哪里。CMD 里执行：
where node输出通常有两个来源，一个是 C:\nodejs\node.exe，另一个可能是你以前装的旧 Node（如果有残留）。如果输出里有多个 node.exe，PATH 顺序就很重要。再执行：
node -e "console.log(process.execPath)"这个命令能直接打印出当前 node.exe 的物理路径，看清楚它落在哪个版本目录。如果它打印的路径不是 C:\nvm\vxx\node.exe，而是某个残留的旧目录，说明你的 PATH 顺序有问题，优先调整环境变量，把 C:\nodejs（也就是 NVM_SYMLINK）挪到所有 node 相关路径的最前面。
4. 全局配置node：把npm全局包、缓存全部赶到D盘
4.1 为什么要动npm全局配置
先说一个典型场景：你按第 3 章的默认方式装了几个 node 版本，每个版本都手动装了一遍全局工具。终于有一天你受不了了，问自己：能不能让全局包只装一份，不管切换哪个 node 版本都能用？
答案是可以的。思路是让 npm 的 prefix 指向一个固定目录，这个目录不在任何版本文件夹内部，这样无论当前激活哪个 node 版本，npm 全局安装都会往这个固定目录写。使用方只需要把该目录下的命令文件夹加入 PATH。
这个需求其实非常普遍，毕竟没人希望切一次 node 版本就把 vue-cli、yarn、pnpm 全部重装一遍。对应热搜词里的“nvm安装及全局配置node”，这一步就是“全局配置”的核心。
4.2 三步把npm全局根目录固定到D盘
假设你的固定目录计划放在 D:\nodejs 下，下面是完整的操作步骤。
第一步：创建两个目录
mkdir D:\nodejs\npm-global mkdir D:\nodejs\npm-cache第二步：设置 npm 全局配置，打开任意 CMD 或 PowerShell 执行：
npm config set prefix "D:\nodejs\npm-global" npm config set cache "D:\nodejs\npm-cache"npm 会把这两个配置写进用户目录下的 .npmrc 文件（路径是 C:\Users\你的用户名.npmrc）。这个文件所有 node 版本共用，所以配置一次，全局生效，切换版本也不变。
验证一下：
npm config get prefix npm config get cache输出应该都是 D:\nodejs 下的路径。
第三步：把 D:\nodejs\npm-global 加进 PATH，并且把它放到比所有 node 相关路径更靠前的位置。
在 Windows 的“编辑环境变量”界面里，选中 PATH 点击编辑，新增一行：
D:\nodejs\npm-global把它上移，直到它排在其他 node 路径之前。
为什么要强调顺序？因为 npm 全局包在 Windows 下生成的命令行脚本不是真正的 exe，而是 .cmd 文件。当你敲 yarn 时，系统会在 PATH 里从头到尾找 yarn.cmd。如果旧版本的 node 自带目录里恰好也有个同名脚本，顺序不对就会启动错的那一个。
完成后，新开一个 CMD 窗口验证：
npm install -g http-server http-server -v能正常输出版本号，说明固定全局包配置已经生效。以后不管 nvm use 哪个版本，http-server 都不会消失，也不用重新安装。
4.3 顺手把registry也配好，少走一大段弯路
在 Windows 上装 nvm 时，大概率会遇到 nvm install 下载 node 压缩包过慢甚至卡死的问题。node 官方二进制包托管在 GitHub 上，国内网络条件时快时慢。但这里有一个操作很多人不知道：nvm 下载 node 使用的是它自己配置的镜像地址，这个地址写在一个叫 settings.txt 的文件里。
打开 C:\nvm\settings.txt，内容通常是这样：
root: C:\nvm path: C:\nodejs arch: x64 proxy: none如果需要加速，可以在文件末尾加一行镜像配置：
node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/保存后重新打开 CMD，再执行 nvm install，下载速度通常会有质的提升。如果你用的是第 2 章的 D 盘方案，settings.txt 就在 D:\nvm 下，路径对应改一下。
顺手把 npm 的 registry 也切到国内镜像，减少全局包下载失败概率：
npm config set registry https://registry.npmmirror.com这个配置同样写在 .npmrc 里，对所有 node 版本生效。
4.4 全局包与node版本错配的一个真实事故
把全局包固定到 D 盘之后，有一个坑等着你：全局包不再随 node 版本切换而隔离，于是版本错配问题就出现了。
举个真实例子。我手上某个老项目依赖 Node 14，而另一个新项目依赖 Node 20。固定全局包目录后，D:\nodejs\npm-global 里的某个工具（比如 node-sass 相关的编译型模块）是当初在 Node 20 下编译的，切换到 Node 14 后某些 native 模块直接加载失败，报错信息各种难以理解。
处理方案有两个：
- 对纯 JS 工具（yarn、http-server、vue-cli 这类），固定全局目录基本不会出问题，放心用；
- 对带原生编译模块的工具（node-sass、bcrypt、sharp、robotjs 这类），如果报错，就在当前 node 版本下执行一遍：
npm rebuild或者干脆在项目局部用 npx 代替全局安装，别让全局目录背负太多兼容压力。
所以我现在给自己定了个规矩：固定全局目录只放高频且纯 JS 的命令工具，项目依赖一律走 package.json 的 devDependencies。这样既享受了全局固定目录的便利，又避开了版本错配的雷区。
5. 高频报错“nvm could not be found”的完整排查链路
5.1 报错长什么样，什么时候触发
先复现一下这个报错的完整形态：
nvm could not be found or does not exist. exiting. no installations recognized我见过好几个人卡在这一步，第一反应是“nvm 坏了”，然后卸载重装，装了之后还是报同样的错。其实这个错误出现的场景高度雷同：刚装完 nvm，还没 nvm install 过任何版本，就直接敲 nvm use 18。
或者，已经 nvm install 18 了，但 install 过程中断失败，磁盘里只有一个残缺的版本目录。再或者，输入了 nvm list 能看到的版本号，nvm use 仍然报 not found。
这个报错的本质就一句话：当前 nvm 可识别的版本列表里，没有你要求激活的那个版本。但“列表识别不到”背后的原因可以有很多层，下面按顺序排查。
5.2 排查链路第一步：nvm list 与磁盘目录对账
新开一个 CMD，先执行：
nvm list如果输出是空，说明 nvm 完全没有识别到任何版本。这时候打开 nvm 安装目录看一眼，有没有 v16、v18 这样的文件夹？
如果文件夹存在但 nvm list 空白，问题大概率出在 settings.txt 的 root 字段与实际目录不一致。比如你从别的电脑拷贝了 nvm 目录，或者安装完后手动移动过位置，root 还指着旧的绝对路径。此时 nvm 拿着旧路径去找版本，自然找不到。
如果 nvm list 里有版本号，执行 nvm use 仍然报 not found，再看看你输入的版本号是不是和 list 完全一致。nvm use 18 不等于 nvm use v18.20.4，nvm-windows 对版本号的匹配比较死板，建议直接复制 nvm list 输出的完整版本号，别手敲。
5.3 排查链路第二步：环境变量是否真的被读到
很多时候报错和环境变量有关。CMD 里分别执行：
echo %NVM_HOME% echo %NVM_SYMLINK%如果你看到的是空值或者还指向安装前的旧路径，说明环境变量没配好。尤其注意：修改了环境变量后，已经打开的 CMD 窗口不会更新，必须全部关闭再重新打开。我见过有人改完环境变量，在旧窗口里试了七八次都失败，最后新开窗口一下就成功了。
再检查一下 PATH 里有没有同时存在多个 nvm 相关路径。比如你以前手动装过 nvm 到 C:\nvm，后来又用安装包装了 D:\nvm，PATH 里可能两条都有，CMD 会优先命中排在前面的那一个。这样的“双 nvm”配置，版本列表和链接目录互相错位，报错是必然的。解决方案：删掉废弃的那一条，只保留当前真正在用的 NVM_HOME。
5.4 排查链路第三步：settings.txt的root、path与arch字段
settings.txt 是 nvm-windows 的命根子。它里面的 root、path 和 arch 三个字段，分别对应 NVM_HOME、NVM_SYMLINK 和系统架构。一个典型的正确写法如下：
root: D:\nvm path: D:\nodejs arch: x64 proxy: none检查要点有四个：
- root 必须和实际 nvm 安装目录一致，不能带引号，不能带结尾反斜杠；
- path 必须和 NVM_SYMLINK 指向一致；
- arch 如果是 x64，安装 node 时 nvm 会按 64 位版本下载；如果写成 x86，即使你系统是 64 位，下载的 node 也可能是 32 位版本，导致部分包行为异常；
- 文件编码保持纯 ASCII，不要用带 BOM 的 UTF-8 保存，否则 nvm 读取时可能解析失败。
再补一个细节：如果你改了 settings.txt，记得重新打开命令行窗口。nvm 是在启动时读取配置的，你在编辑完配置后继续用旧窗口操作，它读到的还是旧配置。
5.5 排查链路第四步：Windows目录联接权限被拦截
这个坑比较隐蔽。nvm use 成功执行后，理论上 NVM_SYMLINK 指向的目录（比如 C:\nodejs）应该立刻生效。但如果你执行 node -v 发现找不到 node，或者提示“无法将‘node’识别为命令”，有可能是 C:\nodejs 软链接没有创建成功。
在 CMD 里执行：
dir C:\看看 C:\nodejs 是不是存在，并且右键属性里能不能看到类似“快捷方式”的标志。如果 C:\nodejs 根本不存在，重新执行一次：
nvm use 18.20.4再看是否报“create symlink”相关错误。如果报错，十有八九是杀毒软件或者组策略禁止了创建 junction。nvm-windows 创建 nodejs 链接目录用的是 mklink /J，普通权限下一般能成功，但部分安全软件会拦这个操作。临时退出杀软，或者用管理员身份打开 CMD 再执行 nvm use，试试能不能恢复。
这里要说一句：杀毒软件的问题不在本文讨论范围内，但如果你的电脑是企业统一安装的终端管控软件，这个问题可能不是你个人能解决的，需要找 IT 开白名单。
5.6 排查链路第五步：警惕“安装包不合法”这种源头问题
回到热搜里的“windows如何安装nvm的v0.40.8版本”。如果你从非官方渠道下载了一个名为“nvm v0.40.8”的安装包，装完出现各种诡异问题，我建议直接放弃它，回到官方仓库重新下载 1.x 版本。
理由很简单：Windows 上的 nvm 官方版本是 1.x，原版 shell 脚本 nvm 才是 0.40.x。一个 Windows 安装包却带着 0.40.8 版本号，本身就说明它来路不明或者教程编排有误。为了环境和系统安全，下载软件永远走官方渠道，这是最省事也最安全的做法。
6. 日常版本切换与卸载清理：从安装到走人的完整动作
6.1 高频命令速查表
把日常最常用的 nvm-windows 命令整理成一张表，方便查阅：
| 命令 | 作用 |
|---|---|
| nvm install | 安装指定版本，如 nvm install 18.20.4 |
| nvm use | 切换到指定版本 |
| nvm list | 查看已安装的所有版本 |
| nvm list available | 查看远程所有可下载版本 |
| nvm current | 查看当前正在使用的版本 |
| nvm uninstall | 卸载指定版本 |
| nvm alias default | 设置默认启动版本 |
| nvm which | 查看某个版本的物理安装路径 |
设置默认版本有一条经验供参考：装完 nvm 后新开的 CMD 窗口不会自动激活任何版本，需要手动 nvm use。如果你希望每次打开终端自动进入某个版本，执行：
nvm alias default 18.20.4之后新开的窗口会默认使用这个版本，省去反复 nvm use。
6.2 .nvmrc与项目级版本固定
如果你同时维护多个项目，不同项目依赖不同 Node 版本，强烈建议在每个项目根目录放一个 .nvmrc 文件，内容只写版本号：
# 文件内容示例 18.20.4切目录时，在项目路径下执行 PowerShell 命令：
nvm use (Get-Content .nvmrc -TotalCount 1)nvm-windows 本身没有像原版 nvm 那样在 cd 时自动读取 .nvmrc 的能力，但这个一条命令的办法效果差不多。配合nvm alias default，我日常在项目间切换基本不会再敲错版本号。
另外一个小习惯：每次切换版本后先看一眼全局包是否还在。因为如果你没做第 4 章的固定全局目录配置，切版本后以前的全局工具会凭空“消失”，这是 nvm 的隔离设计，不是故障。先执行一下npm ls -g --depth=0确认现状，再决定要不要装。
6.3 卸载nvm的正确姿势
不打算继续用 nvm 了，想回到独立安装 Node 的老路？不要直接删文件夹了事，按顺序执行清理：
- 卸载所有 node 版本：
nvm uninstall 18.20.4对所有已安装版本重复执行，直到 nvm list 为空。
- 删除 nodejs 链接目录 C:\nodejs。不要用 del /s，不要进资源管理器狂删。CMD 里执行：
rmdir C:\nodejsrmdir 在删除 junction 时会直接移除链接本身，不会递归删掉它指向的版本目录。如果你用资源管理器删除，虽然通常也安全，但碰到某些工具把它当作普通文件夹递归遍历，可能把 C:\nvm 里的实际文件一起干掉。
运行 nvm-windows 的卸载程序，或者在“控制面板 -> 程序和功能”里卸载。
手工清理环境变量，删除 NVM_HOME、NVM_SYMLINK，以及 PATH 里对应的 %NVM_HOME%;%NVM_SYMLINK% 两条。安装程序的卸载不会帮你清理这些，不清的话系统 PATH 里会残留一堆没用的路径。
删除 nvm 安装目录里剩余的文件，包括 settings.txt 和所有版本文件夹。
如果设置了固定 npm 全局目录，PATH 里的 D:\nodejs\npm-global 也要移除。
.npmrc里的 prefix 配置可以保留，也可以随手删掉，看你自己。
这套流程做完之后，系统才算真正回到“没有 nvm”的干净状态。之后再装独立的 Node.js，就不会出现两个环境互相干扰的问题。
我自己现在的最终布局是：nvm 装在 D:\nodejs-tools\nvm，symlink 指向 D:\nodejs-tools\nodejs，npm 全局包固定到 D:\nodejs-tools\npm-global。这套结构保持了三条铁律：路径无空格无中文、链接目录恒定不变、全局包脱离具体版本。装好头一天把 nvm 的 settings.txt 和 .npmrc 一次性配完，后面再没操过心。最后分享一个小技巧：遇到和 node 相关的玄学报错，先执行where node看看到底有几个 node 在抢同一个命令，八成问题都能从这个输出里找到线索。
