艾格吃饱了我真正决定把 nvm 用起来，是在连续两周被三个项目不同版本的 node.js 折腾到没脾气之后。老项目构建只认 node 12，新项目要求 node 18+，还有个跑批脚本在 node 10 下才正常——每换一个项目就得改一次环境变量，稍不注意就把系统环境改坏。后来用上了 nvm（Node Version Manager），本质就是给 node.js 装一个版本管理工具，这个问题才算彻底根治。
这篇文章不铺垫理论，直接走一遍从下载 nvm、安装、配置全局环境，到用 nvm 装 node.js、切换版本、排错修复的完整流程。适合前端开发者、刚学 node.js 的小白，以及被多项目版本冲突折磨的运维和后端开发同学参考。
1. 为什么要用nvm管node.js——先搞清楚它到底是干什么的
1.1 一句话搞懂node.js和nvm的关系
node.js 是一个 JavaScript 运行环境。以前 JavaScript 只能跑在浏览器里，node.js 让它能跑在操作系统上，于是前端工程化工具（Webpack、Vite）、后端服务（Express、Koa）、命令行工具，全都围绕 node.js 长出来了。可以这么理解：node.js 是发动机，各种工具链是装在发动机上的设备。
但发动机也有版本。node.js 迭代非常快，每年一个大版本，而且大版本之间经常有破坏性变更。比如 node 12 能跑的旧项目，升级到 node 18 大概率报错；反过来，node 18 下用的新语法，node 10 根本不认识。nvm 就是给 node.js 装一个“多系统引导管理器”，像电脑上装了 Windows 和 Linux，开机时选择进哪个系统。nvm 让你在终端里随时切换当前使用的 node.js 版本，互不干扰。
nvm 的全称是 Node Version Manager，目前 Windows、macOS、Linux 都有对应的发行版。Windows 上最常用的是 nvm-windows，由 coreybutler 维护；Mac/Linux 上则是 nvm-sh 维护的原版 nvm。两者思路一致，命令略有差异，后面我会分别讲。
1.2 不用nvm直接装node.js会遇到哪些坑
先说我踩过的几个真实场景。
第一个是全局工具链崩溃。我当时直接安装了官网最新的 node，npm 全局装了若干工具，一切正常。后来另一个项目需要 node 12，我直接把新版 node 卸载、装回 node 12，结果所有全局工具全部失效，因为新版 node 的目录结构和全局包存放路径跟旧版不完全一样，卸载时连带着把全局包一起清掉了。来回折腾一下午，最后全量重装。
第二个是项目版本冲突。一个团队里，老项目要 node 12，新项目要 node 18。如果没有版本管理工具，你只能在系统里反复卸载、安装，每次切换至少十分钟起步，而且很容易把依赖装错版本。这个问题在多人协作环境里更严重——你永远不知道同事的环境到底哪一步配置错了。
第三个是“卸载不干净”的麻烦。Windows 上直接卸载 node.js，经常会留下 C:\Program Files\nodejs、%APPDATA%\npm、%APPDATA%\npm-cache 这些残留目录，以及 PATH 里的旧路径。下次装新版时，where node 一查，可能指向一个早就被删掉的历史路径，命令却显示正常，非常迷惑。
所以我的结论很明确：如果你要在电脑上长期使用 node.js，第一步就应该先装 nvm，而不是直接去官网下安装包。 版本管理这件事做得越早，后面要填的坑越少。
1.3 nvm的核心工作方式：软链接与版本目录隔离
nvm 的实现原理其实不复杂，理解它对你排错很有帮助。
原版 nvm（Mac/Linux）会把所有版本的 node 下载到 ~/.nvm/versions/node 目录下，然后通过修改 PATH 环境变量，把当前要使用的版本目录放在最前面。所以当你执行 node -v 时，系统找到的是 ~/.nvm/versions/node/v20.11.1/bin/node，而不是系统目录下的 node。
nvm-windows 的思路类似，但实现略有不同。它维护一个 NVM_ROOT 目录（例如 C:\nvm），所有 node 版本下载并解压到 C:\nvm\v20.11.1 这样的子目录中。然后它会创建一个符号链接目录（例如 C:\nodejs），这个链接指向当前选中的版本目录。最终 PATH 里配置的是 C:\nodejs，而不是具体某个版本目录。
这个机制的好处是：切换版本时，nvm 只需要改一下符号链接的指向，不需要动系统里的其他文件。坏处是：一旦符号链接失效或 PATH 顺序有问题，就会出现“nvm list 能看到版本，但 node -v 还是老版本”的诡异现象。后面第 5 章我会专门讲这类问题的排查方法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 装nvm之前的准备工作：先处理掉旧node.js环境
2.1 检查电脑上现有的node.js环境
安装 nvm 之前，第一步是检查系统里是不是已经装了 node.js。如果装了，建议先卸载干净，再通过 nvm 统一管理，否则容易形成两条管理路径互相打架的局面。
Windows 下打开命令提示符（cmd）或 PowerShell，依次执行：
bash复制node -v
npm -v
where node
where npm
如果显示了版本号和路径，说明系统里已经存在独立的 node.js。如果提示“不是内部或外部命令”或“无法识别”，说明还没装，或者装了但没配置环境变量。
Mac/Linux 下用：
bash复制node -v
npm -v
which node
which npm
无论输出结果如何，都建议先记录下这些信息，尤其是路径，后面清理时会用到。
2.2 彻底卸载旧node.js的完整步骤
Windows 上卸载 node.js，不能只靠控制面板里的“卸载程序”。为了后面少踩坑，建议按下面的顺序操作：
- 控制面板卸载：进入“设置 → 应用 → 安装的应用”，找到 Node.js，先正常卸载。
- 删除残留目录：卸载完成后，手动删除以下目录（如果存在）：
- C:\Program Files\nodejs
- C:\Users<你的用户名>\AppData\Roaming\npm
- C:\Users<你的用户名>\AppData\Roaming\npm-cache
- C:\Users<你的用户名>\AppData\Local\Temp 里和 node 相关的临时文件
- 清理环境变量：右键“此电脑 → 属性 → 高级系统设置 → 环境变量”，在用户变量和系统变量的 PATH 中，删掉所有包含 nodejs、npm 的路径。
- 验证清理结果：重新打开一个终端窗口，执行 node -v，确认提示不存在。
Mac/Linux 上的卸载相对简单，一般用官方安装包安装的，可以执行：
bash复制sudo rm -rf /usr/local/bin/node
sudo rm -rf /usr/local/bin/npm
sudo rm -rf /usr/local/lib/node_modules
如果之前是用 Homebrew 安装的，则用 brew uninstall node 更干净。
注意：如果你只是想体验 nvm，暂时不想卸载旧 node，也不要直接装 nvm — 必须先卸载。否则 nvm use 切换版本后，系统 PATH 里旧 node 的路径可能排在前面，导致切换无效，这是新手最容易卡住的问题之一。
2.3 卸载node.js报错2053的处理思路
有些人在卸载 node.js 时会遇到“安装程序被中断，错误码 2053”之类的提示。这个错误码没有特别权威的官方文档说明，但根据实际排查经验，大概率是 Windows Installer 的缓存或系统权限出了问题。
我试过几种处理思路，按推荐顺序排列：
- 重新运行官方安装包：去 node.js 官网下载和已安装版本一致的 .msi 安装包，运行后选择“Repair”（修复），修复完成后再到控制面板卸载。这个方法能解决大部分卸载失败的问题。
- 用专业卸载工具：比如 Geek Uninstaller，它能扫描并清理注册表残留项，对顽固的卸载错误通常有效。
- 手动清理注册表：这是最后手段。打开注册表编辑器（regedit），搜索并删除 Node.js、nodejs 相关的项。操作前务必先备份注册表，不建议新手直接动注册表，删错系统项可能导致其他软件异常。
处理完 2053 之后，再清理残余目录和环境变量，确保 where node 没有输出，再进行下一步。
2.4 检查并清理PATH环境变量
卸载完成后，PATH 环境变量里可能还残留着旧 node 路径。很多人忽略这一步，导致安装 nvm 后执行 node -v，报的却是“找不到 node”或“node 不是内部命令”。
具体操作：
- 打开环境变量编辑界面（Windows 下按 Win + R，输入 sysdm.cpl → 高级 → 环境变量）。
- 在“用户变量”和“系统变量”中分别找到 PATH，逐个检查。
- 删除所有包含 nodejs 的条目。注意保留其他条目，不要误删。
- 保存后，务必关闭并重新打开终端，让新的环境变量生效。
Mac/Linux 下检查 PATH 的方式是执行 echo $PATH，看有没有指向旧 node 的路径。如果需要清理，编辑对应的配置文件（~/.bashrc、~/.zshrc 等）即可。
3. nvm下载与安装实操（Windows为主，WSL/Linux/macOS补充）
3.1 下载前先选对nvm版本和下载渠道
Windows 上用的 nvm-windows 和 Mac/Linux 的原版 nvm 是两套独立项目，不要混用安装方式。
nvm-windows 的最新版本通常可以在 GitHub 上 coreybutler/nvm-windows 的 Releases 页面找到。你需要下载的文件是 nvm-setup.exe，这是图形化安装程序，适合绝大多数人。另有一个 nvm-noinstall.zip，属于绿色免安装版，适合喜欢自己配置环境变量的老手，新手不建议用。
原版 nvm（nvm-sh/nvm）没有 Windows 安装包，Mac/Linux 上是通过 curl 执行安装脚本。这个我放到 3.4 节单独讲。
关于下载速度：如果 GitHub 的 Releases 页面访问缓慢或下载卡顿，可以使用 GitHub 下载加速镜像，或者搜索 nvm-setup.exe 的镜像站。这里不展开具体工具，核心思路就是找可信的镜像地址。另外，nvm 安装过程中的 node 版本列表下载、node 安装包下载，也会走 remote 地址，如果网络环境不好，后面还会遇到“版本列表为空”或“下载失败”的问题，我会在第 5 章给出对策，不要只卡在安装这一步。
3.2 安装向导的关键选项：目录别带空格和中文
双击 nvm-setup.exe 后，会进入安装向导。这里有两个关键步骤，直接决定后面是否省心。
第一个是 nvm 安装目录。默认是 C:\Users<用户名>\AppData\Roaming\nvm，这个路径可以，但有些老用户习惯改成 C:\nvm。注意，安装路径不要包含空格和中文，比如 C:\Program Files\nvm 这种就别选，nvm 在调用 node 版本时对空格路径处理得不好，容易出莫名其妙的问题。
第二个是 Node.js 符号链接目录。安装向导会让你选一个路径作为 Node.js 的“软链接”位置，默认是 C:\Program Files\nodejs。我建议改成 C:\nodejs，原因同样是为了避免空格。这一步需要记住最终路径，后面配置环境变量时会用到。
安装完成后，nvm 会自动配置两个环境变量：
- NVM_HOME：指向 nvm 程序所在目录
- NVM_SYMLINK：指向符号链接目录（比如 C:\nodejs）
同时会把 NVM_HOME 加入 PATH。不需要手工额外配置，但如果装完发现 nvm 命令找不到，优先检查这两个变量是否存在。
3.3 安装后验证：nvm命令是否可用
安装完成后，重新打开一个 cmd 或 PowerShell（注意是新的终端窗口，旧窗口不会自动加载新环境变量），执行：
bash复制nvm version
如果输出版本号（比如 1.1.12），说明安装成功。如果提示“nvm 不是内部或外部命令”，按下面两步排查：
- 检查环境变量是否正确写入。执行
echo %NVM_HOME%和echo %NVM_SYMLINK%，确认两个变量有值。 - 如果变量有值但命令不生效，手动把
%NVM_HOME%加到 PATH 里，保存后重开终端。
这一步通过后，执行：
bash复制nvm list
此时应该显示类似 No installations recognized 或只有 current 指向的空白列表，说明 nvm 已经就绪，但还没有安装任何 node 版本。
3.4 WSL/Linux/macOS下的nvm安装差异
如果你用的是 WSL、Linux 或 macOS，安装方式就不同了。原版 nvm 的安装脚本来自 nvm-sh/nvm，标准命令是：
bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
安装完成后，脚本会把 nvm 的初始化代码写入 ~/.bashrc 或 ~/.zshrc。你需要重新加载配置文件：
bash复制source ~/.bashrc
然后执行 nvm --version 验证。
如果所在网络环境下 raw.githubusercontent.com 不通畅，下载会卡住。替代方案有几个：一是用 Gitee 上同步的 nvm 镜像脚本，二是把 install.sh 下载到本地后手动执行，三是设置 NVM_SOURCE 环境变量指向国内可达的镜像地址。这里尤其注意，不要去找来路不明的第三方脚本直接管道到 bash——安全第一。
Windows WSL 里安装时，还有一个点需要提醒：WSL 里的 node 环境和 Windows 里的 node 环境是完全隔离的。你在 Windows 装 nvm、在 WSL 里也要装一套 nvm，两者互不影响。很多新手装了 Windows 版 nvm 后发现 WSL 里 node -v 没有反应，就是因为隔离机制。
4. 用nvm安装node.js版本：从选版本到全局配置
4.1 别急着装最新版，先看可用版本列表
nvm 安装完成后，第一件事不是直接 nvm install latest，而是先看看远程有哪些版本。
Windows 上的 nvm-windows 执行：
bash复制nvm list available
这会输出一个当前可安装的版本列表。新版 nvm-windows 还会按“Current”、“LTS”、“Old versions”等分类显示。注意，如果你配置了镜像源，列表会来自镜像；如果配置不对，可能列表为空或版本不全，这个后面讲。
Mac/Linux 的原版 nvm 执行：
bash复制nvm ls-remote
它会列出所有远程版本，末尾通常标记 Latest LTS 版本。
关于版本号，node.js 有一个规律：偶数版本号是 LTS（比如 18、20、22），奇数版本号是 Current（比如 21、23）。生产环境建议选偶数版本，追求稳定。个人学习和实验可以选最新 Current 版本尝鲜。
我的习惯是：优先装当前 LTS，再装一个当前机器上老项目需要的低版本。这样既保证新项目能用上新特性，老项目也不会反复切换崩溃。
4.2 安装、切换、设置默认版本：一条龙操作
假设我要安装 node 20.11.1，执行：
bash复制nvm install 20.11.1
Windows 下会先显示下载进度，然后自动解压到 NVM_HOME 下的 v20.11.1 目录。安装完成后，可以用 nvm list 查看本地已安装的版本。
切换到指定版本：
bash复制nvm use 20.11.1
这里有个 Windows 特有的问题：nvm use 需要管理员权限。如果你在普通终端里执行，可能会提示“需要管理员权限”或直接报错。解决方法：右键点击“命令提示符”或“PowerShell”，选择“以管理员身份运行”，再执行 nvm use。
切换成功后，执行：
bash复制node -v
npm -v
确认两个命令的版本都发生了变化。如果 node -v 变了但 npm -v 没变，通常是旧 npm 的全局路径残留问题，我在 4.4 节会具体讲。
最后，强烈建议设置一个默认版本，否则每次打开新终端，node 可能都是空的：
bash复制nvm alias default 20.11.1
设置后，新开的终端会自动使用这个版本，不需要每次手动 nvm use。
4.3 配置npm镜像和全局路径
装完 node.js，顺手把 npm 的 registry 改成国内镜像，能大幅提升依赖安装速度和成功率。这个操作不是 nvm 的必需步骤，但基本是实际开发的标配。
执行：
bash复制npm config get registry
如果是默认值 https://registry.npmjs.org/，建议改成淘宝镜像（现在叫 npmmirror）：
bash复制npm config set registry https://registry.npmmirror.com
设置后再次执行 npm config get registry 确认生效。
另外，npm 默认的全局安装路径和缓存路径，在 Windows 上确实有点绕，建议统一管理。执行：
bash复制npm config set prefix "C:\nodejs\node_global"
npm config set cache "C:\nodejs\node_cache"
然后手动创建这两个目录即可。之后通过 npm install -g 安装的工具，都会集中在这两个目录里，清理和排错都方便很多。
注意：修改 prefix 后，记得把新增的全局 bin 目录加入 PATH。Windows 下是 C:\nodejs\node_global，Mac/Linux 下通常是 ~/.npm-global 或 ~/.nvm/versions/node/<版本>/bin。否则 npm 全局装了一个命令，终端却找不到。
4.4 切换node版本后，npm全局包“消失”是正常的吗
这是新手问得最多的一个问题：我在 node 20 下全局安装了某个 CLI 工具，切到 node 18 后，执行这个命令提示“找不到”，是不是 nvm 把我的包搞坏了？
其实不是。nvm 的设计初衷就是每个 node 版本拥有独立的环境，包括独立的全局包目录。在 Windows 上，nvm-windows 不会共享全局包，不同版本的 node 对应不同的 node_modules 目录。所以切换版本后，原来的全局命令暂时不可用，是正常现象。
解决方式有两种思路：
- 在需要的版本下重新安装全局工具。如果常用工具不多，这是最直接的办法。
- 使用 pnpm 或 yarn 的全局配置，把全局包集中到一个固定的位置，并手动加入 PATH。不过这种方法较为进阶，对新手反而会增加理解成本。
我个人的做法是：同一台机器上尽量保持 node 版本相对统一。如果确实需要多个版本长期共存，那就接受“每个版本各装一遍全局工具”的现实，或者干脆在项目里用 pnpm，把工具类依赖放进 devDependencies，由项目自身管理，减少对全局包的依赖。
4.5 查看端口占用、定位node服务问题的两条常用命令
既然装了 node.js，再说一个开发中高频会遇到的操作：查端口占用。node 服务一崩，最常见的就是端口被之前残留的进程占着，重启报 EADDRINUSE。
Windows：
bash复制netstat -ano | findstr :3000
tasklist | findstr <PID>
第一行能看到 3000 端口对应的 PID，第二行能查到哪个进程占用了这个 PID。确认是自己残留的 node 进程后，用 taskkill /PID <PID> /F 强制结束。
Mac/Linux：
bash复制lsof -i :3000
kill -9 <PID>
这两组命令是我排查 node 服务报错的第一板斧，几乎每周都用得上，建议记下来。
5. 常见报错排查实录：把这些年踩过的坑一次性说清
5.1 报错“xx版本is not yet released or is not available”
这是 nvm-windows 用户很容易遇到的一种报错，比如输入：
bash复制nvm install 24.19.0
然后得到：
code复制error installing 24.19.0: node.js v24.19.0 is not yet released or is not available
单看字面意思，是说这个版本还没有发布或者不可用。但实际有两种可能：
原因一：版本号确实不存在或未发布。 解决方案很简单，先执行 nvm list available 看看当前远程源里有哪些版本，从中挑一个真实存在的版本号再安装。
原因二：远程版本列表没有完整同步。 如果你的 nvm-windows 配置了镜像节点，而镜像节点没有及时同步最新版本，那么列表里可能缺少某个新版本号。此时你手动输入的版本号不在列表里，nvm 就认为是“not yet released”。解决方案：检查 nvm 根目录下的 settings.txt，看有没有配置镜像源。
settings.txt 的常见位置是 nvm 安装根目录，比如 C:\nvm\settings.txt。里面通常有两行：
code复制root: C:\nvm
path: C:\nodejs
如果之前为了加速手动添加过 node 镜像地址，在 nvm-windows 中是通过环境变量或配置文件里的 node_mirror 和 npm_mirror 字段控制。干净的配置通常长这样：
code复制root: C:\nvm
path: C:\nodejs
node_mirror: https://npmmirror.com/mirrors/node/
npm_mirror: https://npmmirror.com/mirrors/npm/
如果你不确定自己配置的是什么，直接先去掉 node_mirror 和 npm_mirror，恢复默认官方源，再执行一次 nvm list available。重新拉取列表后，版本通常就会完整了。
注意：切换镜像源后，修改 settings.txt 需要保存并重新打开终端才能生效。不需要重启电脑，但一定要重开终端窗口。
5.2 切换node版本后，node -v还是旧版本
这种问题绝大多数出在 Windows 环境。现象是：nvm use 12.22.12 显示切换成功，但执行 node -v 还是 18.x 或 20.x。
第一排查点：where node。执行：
bash复制where node
正常情况下，输出应该指向 NVM_SYMLINK 对应的路径，比如 C:\nodejs\node.exe。如果输出指向其他路径（比如 C:\Program Files\nodejs\node.exe），说明 PATH 里还残留旧 node 的路径，而且它的优先级比 C:\nodejs 高。清理掉 PATH 里其他 node 相关路径，只保留 C:\nodejs 即可。
第二排查点：终端是否用管理员权限。我刚才提过，nvm-windows 的 nvm use 需要以管理员身份运行。如果普通终端执行 nvm use，有的版本会静默失败，等你看 node -v 时它根本没切换。解决方式：管理员权限重开终端，重新 nvm use。
第三排查点：符号链接是否失效。如果 C:\nodejs 目录本身变成了一个普通目录（而不是符号链接），nvm 切换时可能无法正确更新。可以手动删除 C:\nodejs 目录（注意不是删除 node 版本目录），然后重新执行 nvm use，nvm 会自动重建符号链接。
5.3 装完nvm后，nvm list available显示列表为空
如果执行 nvm list available 时没有输出任何版本，Windows 下通常有两个原因：
一是网络无法访问远程版本列表地址。nvm-windows 读取版本信息的地址是 https://nodejs.org/dist/index.json 或配置的镜像地址。如果这里不通，列表自然为空。解决办法是配置可访问的 node_mirror，比如前面提到的 npmmirror 镜像。
二是 nvm 版本太老。老版本的 nvm-windows 在解析新版的 index.json 时偶发兼容问题。建议直接升级到最新版，或重新下载 nvm-setup.exe 覆盖安装。
Mac/Linux 下如果 nvm ls-remote 为空，先检查 NVM_SOURCE 是否被设成了不可用的镜像，取消该环境变量后重试。如果网络环境不太好，也可以试着重启网络或换网络环境。
5.4 软件提示“node.js not found (please save below and restart)”
这个提示我在一些 GUI 工具里见过，尤其是 IDE 插件、自动化工具或某些桌面软件的配置界面。它的意思是：软件检测不到 node.js 环境，请保存后重启软件。
出现这个提示时，不要急着重装，先自查三个点：
- node 是否真的装了？打开终端执行 node -v。如果没输出，说明 nvm 没设置默认版本，或者 node 尚未安装。执行 nvm ls 确认，并设置
nvm alias default <版本>。 - PATH 中是否有 NVM_SYMLINK 对应的路径？很多桌面软件不会主动读取 nvm 的配置，只认 PATH。确保 PATH 里包含 C:\nodejs（Windows）或对应 nvm 版本目录（Mac/Linux）。
- 软件是否在 node 安装前启动？部分 GUI 软件只在启动时检测一次环境变量，如果你装好 node 后才打开软件，它可能仍保留旧状态。重启软件即可解决。
这些排查点都做过以后，绝大多数“node.js not found”的问题都能解决。
5.5 工具要求特定node版本范围怎么办（openclaw这类情况）
现在越来越多的工具链会在安装时直接声明 node 版本要求，比如 openclaw 安装时会提示：
code复制node.js >=22.22.3 <23, >=24.15.0 <25, or >=25.9.0 is required
这个格式是语义化版本范围（semver range）。拆解一下：它要求你的 node 版本落在以下三个区间之一：22.22.3 到 23（不含 23）、24.15.0 到 25（不含 25）、25.9.0 及以上。
遇到这种提示，直接用 nvm 安装一个符合要求的版本即可。比如：
bash复制nvm install 24.15.0
nvm use 24.15.0
需要注意横向兼容性：如果你的项目里另一个工具锁定的是 node 22 或 node 24，尽可能选择同一大版本内最新的小版本，比如 24.15.0、24.16.0 这种 LTS 系列更新版，它们通常稳定且差距不大。
这个现象也恰恰从侧面说明，nvm 的价值越来越重要——当工具对 node 版本的要求越来越精细时，你不可能为了一个新工具就卸载重装一个 node。nvm 里多装几个版本，随时切换，才是正解。
5.6 打包或部署到没有node.js的电脑上怎么办
有朋友会问：“我用 nvm 管好了本地 node，但要把项目打包到一台没装 node 的电脑上，怎么搞？”这个问题常见于客户端交付场景，或者内网服务器部署。
思路有两条：
思路一：使用可执行文件打包工具。 比如 pkg、nexe 这类工具，可以把 node.js 运行时和你的项目代码一起打包成一个 .exe 文件。目标电脑不需要预先安装 node.js，双击就能跑。这在交付小型工具时非常方便。
思路二：使用 node.js 绿色便携版。 从 nodejs.org 下载 zip 包（Windows 对应 node-v20.x.x-win-x64.zip），解压到目标机器任意目录，然后手动将目录路径加入 PATH。这样相当于一个免安装的 node 环境。因为是绿色版，不需要管理员权限，非常适合内网环境。
这两种方式都能绕开“目标电脑没 node”的限制。我个人的建议是：如果是长期运行的服务器，优先考虑正规安装方式；如果是临时工具或交付演示，绿色便携版最省事。
5.7 老版Windows系统安装node.js的兼容性说明
关于 node.js for Win7，现在官方新版 node 已经不再支持 Windows 7 了。如果你还在老系统上，能装的 node 版本会有上限。
具体来说，node 13 及之前的版本在 Win7 上运行相对稳妥，node 14 之后对操作系统版本有更严格的要求。实际项目里，Win7 用户装 node 12.22.x 或 node 13.x 基本是底线。nvm 在这种场景下依然有用——你可以先用 nvm 装一个老版本 node，避免直接去官网找几十个版本的安装包。
当然，从安全和维护角度看，我还是建议尽快升级操作系统版本，老系统连 npm 依赖本身都会面临越来越多的兼容性问题。
5.8 用nvm装完node后，安装依赖卡在“installing node.js dependencies”
有些工具安装时会显示 installing node.js dependencies (browser tools)...，然后长时间卡住不动。这通常是它在拉取 npm 依赖，但默认源访问太慢。
处理方式很直接：先确认 npm registry 已经设置为镜像源（见 4.3），然后重新执行安装命令。如果还是卡，可以尝试手动依赖安装：先执行 npm install 拉取核心依赖，再回到原工具的安装流程。
另外，这类安装过程对网络稳定性要求高，建议不要开太多代理工具，以免 npm 请求被拦截或走偏。实在不行，就在网络状况好的时间段重试。
5.9 用过程中的“敏感词检测”、“浏览器工具”等长尾说明
热搜词里出现“node.js敏感词检测库”和“installing node.js dependencies (browser tools)”这类内容，虽然和 nvm 没有直接关系，但说明大家搜 node.js 相关问题时，经常遇到“装环境”和“用库”两个阶段混淆的情况。我的建议是：先把环境管理好（即本文这套 nvm 流程），再去研究具体库的用法。很多报错看起来是“库的问题”，其实是当前 node 版本和库要求的版本不匹配导致的——而版本不匹配，正是 nvm 最擅长解决的问题。
给新手的几点实际建议
最后说几句实在的。
nvm 装好后，记得第一件事就是 nvm alias default <版本>，不设默认版本的话，每次开新终端 node 都可能处于“未选择”状态，会让新手非常困惑。
切换版本时，如果提示权限问题，就右键以管理员身份运行终端。不要嫌麻烦，这是 nvm-windows 的固有机制。
另外，如果你同时在 Windows 和 WSL 里开发，一定记住两套环境是独立的，需要分别安装 nvm。这个问题我也经常看到有人踩。
我自己的使用习惯是：本机常驻两个 node 版本——最新 LTS 和一个老项目锁定的版本。日常开发用 LTS，遇到老项目切过去，npm 全局工具按需补充，其余全部交给项目级 devDependencies。这套方式用了几年，node 环境相关的问题几乎没再出现过。