Iris Pan先说一个我最近经常被问到的场景：手上有个维护了两年的老项目，跑的是Node.js 16，但新接的活要求Node.js 18起步，甚至还要用上原生fetch和Web Streams这些新特性。Windows系统下，你不可能每切换一个项目就去官网重新下载安装包，那太折腾了，而且全局安装的全局包也会跟着失效。这时候你需要的，就是在同一台Windows机器上同时装好Node.js 16和18，随时能切，互不干扰。我这次用的工具是winvm-windows，一个专门在Windows上管理Node.js多版本的小工具。这篇文章就围绕这个场景，把完整的安装、切换、排查过程都盘一遍。
如果你也在Windows上做Node.js开发，应该体会过版本错乱的痛苦：全局包装了一堆，某个老项目突然跑不起来，看报错往往就是engine要求Node版本不对；反过来，新项目用了新语法，老版本Node直接不认。下面我先把为什么非要搞双版本这事说透，再一步步演示winvm-windows怎么用，最后把那些坑也一并交代清楚。
1. 为什么要在Windows上同时保留Node.js 16和18
1.1 新老项目并存的现实
Node.js 16在2023年就结束了维护，但实际工作里，大量存量项目还跑在16上。这些项目的依赖树往往带着一堆旧版本的webpack、gulp、node-sass，你贸然切到18，轻则警告刷屏，重则编译直接挂掉。最典型的就是node-sass，它对Node版本极度敏感，16升18之后几乎必然报错。
反过来，新项目选择18的原因也很实际：fetch成为全局API、crypto模块的WebCrypto支持、更快的V8引擎、node:test内置测试模块……这些在16里要么没有，要么不完整。团队成员如果各自为政，有人用16有人用18，锁文件换一版、依赖树就乱一版，最终CI上跑不过，生产环境出问题，大家都很痛苦。
所以双版本不是“图新鲜”，而是日常开发的基本盘。你需要的不是纠结用哪个，而是“我在这个项目里用哪个就切到哪个”。版本切换本身要快、要干净，不残留环境变量垃圾，不影响其他项目。
1.2 官方安装器的局限
很多人一开始会问：Windows直接装两个安装包不行吗？不行。Node.js官方msi安装器本质上是在系统层注册一个固定的Node运行时，全局路径是写死的，比如C:\Program Files\nodejs\。你再装第二个版本，要么覆盖掉原来的，要么安装器提示已存在，根本不让你同时保留。
就算手动把两个版本解压到不同目录，然后手动改PATH环境变量，也只是一个“能用”的最低标准。因为每次切换都要手动去“系统属性 -> 环境变量”里改路径，改完还得重新开终端才生效，而且很容易把全局npm模块目录指向错乱，npm install -g也装到了不知道哪里去。这种方案只适合临时应急，根本扛不住日常高频切换。
还有一个方案是直接改PATH并利用Windows的符号链接，但这是版本管理工具的底层原理，手工操作的话，一个路径写错整条环境变量就废了，新手很容易把系统搞坏。所以专业做法是用工具统一管理。
1.3 版本管理工具的核心思路
Windows上常见的Node版本管理方案其实有好几个，老牌的是nvm-windows，它通过settings.txt配置镜像地址，用符号链接把当前使用的Node版本映射到一个统一目录。我这个标题里提到的winvm-windows，也是同类方案中的一种，核心思路类似：把不同版本的Node下载到各自的目录，然后通过修改PATH环境变量或符号链接，让系统认为当前只有一个Node。
选winvm-windows的原因是它更轻量，命令设计和Linux/macOS上常用的nvm保持一致，winvm install 18.20.4、winvm use 18.20.4这样直来直去，对熟悉*nix工具链的人特别友好。当然，文章后面我也会对照nvm-windows的使用差异，方便你哪个都拿得起来。
总的来说，多版本管理的本质就两个问题：一是“装在哪”，二是“怎么切”。把这两个问题想清楚了，具体用哪个工具只是习惯问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. winvm-windows的安装与核心机制
2.1 安装前的准备
在正式装winvm-windows之前，有几件事建议你先处理好，否则后面容易莫名其妙踩坑。
第一，如果电脑里已经装了官方Node.js，不要急着卸载。可以暂时保留，但要把它的路径从系统环境变量PATH里暂时移掉，或者等winvm-windows装好之后，手动删掉C:\Program Files\nodejs这个目录（如果你确定里面没有重要的全局全局包，建议先npm ls -g看一下）。因为如果两套Node同时存在于PATH里，到底哪个生效取决于环境变量的顺序，非常容易混乱。
第二，准备好一个放工具本身的目录。winvm-windows不一定要装在C盘系统区，我一般放在D:\dev\winvm，因为以后所有Node版本都会装在这个目录的子文件夹里，如果C盘空间紧张，放D盘更安心。
第三，确认你的Windows版本和权限。winvm-windows的安装过程和链接操作会涉及环境变量修改、创建符号链接，普通管理员权限是必须的。我建议直接用管理员身份的PowerShell操作，省得一会儿提示权限不足。
2.2 安装步骤
winvm-windows一般通过GitHub Releases提供压缩包，或者也可以从源码构建。在Windows上，最简单的安装方式是下载压缩包后解压，然后把解压目录加入PATH。我实际操作的版本是把它放在了D:\dev\winvm，解压后结构大概是：
text复制D:\dev\winvm
├─ winvm.exe
├─ settings.json
└─ versions\
versions目录就是之后所有Node版本的家。安装完成后，需要把D:\dev\winvm加入用户环境变量PATH。
在PowerShell里执行：
powershell复制setx PATH "$env:PATH;D:\dev\winvm"
setx会自动写到用户级环境变量，注意它会把原来路径追加在后面。改完重开一个终端，输入：
powershell复制winvm version
能输出版本号，说明工具就绪了。
这里有个细节：setx的字符串长度限制是1024个字符，如果你的PATH特别长，建议去“设置 -> 系统 -> 系统信息 -> 高级系统设置 -> 环境变量”里手动编辑，避免截断原有路径。
2.3 版本切换背后的原理
很多人误以为版本管理工具是“同时激活”了多个Node，其实不是。它只是在你执行winvm use命令时，把当前激活的Node版本从A换成B，核心机制是“符号链接或环境变量替换”。
以winvm-windows为例，它会维护一个统一的入口目录，比如D:\dev\winvm\current。这个目录平时可能不存在，只有当你执行winvm use 18.20.4时，工具才会把D:\dev\winvm\versions\node-v18.20.4这个真实目录，用符号链接的方式映射到current。而PATH里始终只写D:\dev\winvm\current，不会因为切换而反复修改环境变量。
这个设计很聪明：环境变量只在首次安装时改一次，之后每次切换Node版本，只是把符号链接重新指向。这既避免了反复修改系统设置的风险，也让切换速度非常快。
npm的全局模块目录也遵循同样的逻辑。你直接npm install -g装的包，会放在current\node_modules里，切到另一个版本，全局包就是另一套。这很容易让不熟悉的人困惑：刚才还能用的pm2，怎么切版本之后找不到了？其实就是因为全局包是跟着具体版本走的。
注意：Windows某些环境里创建符号链接需要开发者模式或管理员权限。
winvm-windows如果报链接失败，先用管理员身份运行PowerShell，或者检查winvm的settings.json里是否启用了useSymlink选项。
3. 在winvm-windows中安装Node.js 16和18
3.1 安装Node.js 16
现在开始正式操作。先把Node.js 16装好。打开终端（PowerShell或CMD都行），执行：
powershell复制winvm install 16.20.2
16.20.2是Node.js 16的最后一个维护版本，如果你只需要16来跑老项目，选它就够了。工具会自动从官方源下载对应Windows x64的压缩包，解压到versions目录。
下载速度如果很慢，可能是网络问题。winvm-windows的settings.json里通常可以配镜像地址：
json复制{
"registry": "https://npmmirror.com/mirrors/node/"
}
配完重启终端再接install，会明显快很多。
安装完成后可以确认一下目录：
text复制D:\dev\winvm\versions\node-v16.20.2-win-x64
里面就是完整的Node运行时和npm。
3.2 安装Node.js 18
同样方式安装18。我装的是18.20.4，这是18系列最后期的版本，修复了不少关键安全漏洞，推荐直接用这个系列的最高版本：
powershell复制winvm install 18.20.4
这时versions下就有两个完整的Node运行时了：
text复制D:\dev\winvm\versions\node-v16.20.2-win-x64
D:\dev\winvm\versions\node-v18.20.4-win-x64
这里有个小提示：安装时务必记清楚精确版本号。winvm list会列出所有已安装的版本，显示效果类似：
text复制 * 16.20.2
18.20.4
带*的是当前激活版本。如果没有*，说明你还未执行过use。
3.3 切换与验证
装好后，核心操作就是切换。想让系统全局用哪个版本，就激活哪个：
powershell复制winvm use 16.20.2
node -v
# 输出 v16.20.2
winvm use 18.20.4
node -v
# 输出 v18.20.4
切换过程理论上只要一两秒，之所以那么快，本质就是符号链接重新指向。
验证环境是否干净也很重要。建议在每次切换后，在全新的终端窗口执行这几个命令：
powershell复制where node
where npm
node -v
npm -v
where在Windows上会列出所有匹配的可执行文件路径。如果只输出一条，并且指向D:\dev\winvm\current\node.exe，那说明环境是干净的。如果还输出了C:\Program Files\nodejs\node.exe之类的路径，说明老版本残留还在PATH里，需要手动清理。
npm -v也要跟着变，因为npm是Node自带的，正常情况下会随版本切换而变。如果切到18后npm -v还显示16时代的旧npm，大概率是PATH里存在别的npm路径占用了，检查一下where npm。
3.4 项目级固定版本
全局切换只解决了“这台机器上当前用哪个版本”的问题，但实际项目里往往需要更精确的版本约定。我一般会在每个项目根目录放一个.nvmrc文件，内容很简单：
text复制18.20.4
然后写一个项目级命令：
powershell复制$env:NVM_VERSION = Get-Content .nvmrc
winvm use $env:NVM_VERSION
Windows目前没有原生“进入目录自动切换”的能力，所以我通常配合PowerShell的prompt函数，在提示符里检测当前目录下的.nvmrc并自动执行winvm use，体验上已经很接近macOS上的nvm自动切换了。大致思路是这样：自定义PowerShell配置文件$PROFILE，在prompt里拿当前路径，逐级向上找.nvmrc，存在就读取内容，调用winvm use。
这个自动化设置一次之后，以后进到哪个项目目录，终端就自动切到对应Node版本，基本不用再手动干预。
4. 与日常开发工具的配合
4.1 npm版本跟随问题
装了双版本之后，最容易忽略的是npm本身也会跟着版本走。Node.js 16自带npm 8，Node.js 18自带npm 9或10（具体看小版本）。切换后，npm -v会变，这可能导致依赖锁文件的版本变动。
我实测中遇到过一个哭笑不得的情况：项目需要Node 18，但某个老包用npm install安装时对npm版本有要求，提示必须npm 8。这时候不需要更换Node版本，直接在Node 18下npm install -g npm@8把全局npm降级就行——这只会影响当前版本的全局npm，切回Node 16后还是原来的npm 8，两者互不干扰。
这里顺便说明一个误区：winvm切换的是Node运行时，而npm既可以作为某个Node自带的配套工具，也可以作为全局包被单独覆盖。每个版本下的npm状态都是独立的，这本身是优点，但也别忘了“切版本后，全局包要重新检查”。
4.2 pnpm和yarn的使用
现在很多项目已经用pnpm了。Windows下使用pnpm时，建议通过corepack启用。Node.js 16开始官方内置了corepack，不过默认可能没有开启。
在某个版本下启用corepack：
powershell复制corepack enable
pnpm -v
想要给pnpm指定版本可以：
powershell复制corepack prepare pnpm@8.15.9 --activate
yarn则更简单，npm install -g yarn或corepack enable后直接yarn -v。但无论用哪个包管理器，都要记住一个原则：全局工具链的安装，每次切换Node版本后要重新确认。我习惯写一个PowerShell函数，在winvm use之后自动打印当前node、npm、pnpm、yarn版本，一目了然。
winvm-windows本身不强制你装什么包管理器，它只负责Node运行时。所以你的开发环境里“Node 16 + pnpm 8”、“Node 18 + pnpm 9”这种组合是完全可行的，只要切换后重新激活即可。
4.3 终端和IDE的配置
Windows下终端环境五花八门：经典CMD、PowerShell、Windows Terminal、VS Code内置终端。只要PATH配置正确，这些终端基本都能识别node命令。不过有个坑：VS Code如果是在切换版本之前启动的，它的终端环境变量可能还是旧值。解决办法很简单：切换版本后，重启VS Code，或者在新终端里执行RefreshEnv（如果你装了Chocolatey环境刷新工具）或重新加载$PROFILE。
对于IDE里的Node解释器路径设置，比如VS Code的settings.json里如果指定了"node.executable"，这个路径不会自动跟随winvm的符号链接变化，建议直接不设置，让它从PATH里找。
JetBrains系IDE（WebStorm、IDEA）同理，最好把Node解释器设置为“从PATH选择”，或者手动指向D:\dev\winvm\current\node.exe。因为current是符号链接，永远指向当前激活版本，一劳永逸。
5. 常见问题与排查实录
5.1 问题清单速查表
我在实际使用中收集了一些高频问题，整理成表，方便你对照解决：
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
winvm 不是内部或外部命令 |
工具目录没加入PATH | 重新检查环境变量，重开终端 |
node -v 显示的版本不是当前use的 |
PATH里存在旧Node路径 | 用where node排查，清理C:\Program Files\nodejs |
winvm use 提示权限不足 |
符号链接创建失败 | 用管理员身份运行终端 |
切换后 npm -v 不变 |
npm路径被其他工具覆盖 | where npm，检查全局路径顺序 |
npm install -g 装到别的地方 |
用户全局目录或prefix配置被改 | npm config get prefix，重置为current下目录 |
| 项目启动报Node版本引擎不符 | 项目engines字段要求特定版本 | 检查.nvmrc或项目README，切换到对应版本 |
5.2 node命令找不到
新装完winvm-windows或刚换电脑时，经常出现打开终端直接node报“不是内部或外部命令”。这通常是因为winvm use之后符号链接指向失败，或者环境变量没刷新。
处理步骤我建议按顺序来：先执行winvm list，看当前有没有激活版本；再执行winvm use <版本>重新激活；最后一定重开一个新终端窗口测试。如果还是不行，检查一下D:\dev\winvm\current目录是否存在，dir看一下里面有没有node.exe。如果不存在，手动执行winvm use并注意终端是否提示“symlink created”。
还有个隐蔽的问题：某些安全软件会把符号链接当成可疑操作直接阻止，导致current没建出来。遇到这种情况，把D:\dev\winvm加入安全软件白名单即可。
5.3 切换后npm失效
这个问题也不少。切到Node 18后执行npm -v，提示找不到npm，或者npm版本还是老的。先确认一个点：你安装的Node.js 18压缩包是不是完整的。某些非官方镜像下载的压缩包可能缺文件，导致npm脚本缺失。
排除这个之后，再检查D:\dev\winvm\versions\node-v18.20.4-win-x64\node_modules\npm这个目录是否存在。如果存在，大概率是PATH里包含了别的npm路径，比如C:\Users\你的用户名\AppData\Roaming\npm。这个目录是npm全局安装包时创建的，里面也可能有一个npm.cmd的快捷入口。它的存在本身不致命，但如果在系统路径里排在current前面，就会干扰where npm的结果。把D:\dev\winvm\current和versions下的npm目录排到环境变量最前面即可。
5.4 卸载残留与旧环境清理
标题的热搜词里有一条“node.js卸载不了报错2053”，这里也展开说下。Windows下卸载Node.js官方版本，有时会因为Windows Installer缓存或权限问题报错，很恼火。但在用多版本管理工具的场景下，其实不用纠结卸载旧版。只要把旧版的路径从PATH里移除，再把C:\Program Files\nodejs目录改名备份，比如改成nodejs_backup，就相当于“屏蔽”掉了旧版。等确认新环境运行一段没问题再删除备份，比较稳妥。
如果旧版Node还占着某些文件锁，导致安装新版本时出错，重启一次Windows再操作通常就解决了。用winvm安装的新版本都是安静解压，不会动系统全局，也不依赖Windows Installer，所以很少遇到卸载报错那种情况。
还有一种残留是用户目录下的.npmrc文件。它里面如果写了prefix=...或cache=...指向旧路径，会导致切版本后npm行为诡异。建议检查C:\Users\你的用户名\.npmrc，把多余配置清理掉，只保留必要的registry设置。
5.5 多版本全局包的管理心得
我踩过最大的坑，就是误以为全局包可以跨版本共享。项目里随手npm install -g @vue/cli，切到另一个Node版本后vue命令就没了，然后一直纳闷“为什么时有时无”。
实际上，每个Node版本的全局包目录是独立的，这既是隔离性优势，也是麻烦。winvm-windows通常会把全局包目录放在versions\node-vX\下的node_modules里，也有些工具会统一放到一个全局目录，具体看配置。
如果你有一些跨项目都要用的命令行工具，比如typescript、rimraf、cross-env，我给两个方案：
- 在每个Node版本下都单独装一遍，麻烦但最可靠。
- 项目本地安装到
devDependencies，尽量不用全局依赖。
我个人更推荐方案2。全局依赖越少，版本切换的负面影响就越小。现代前端工程化项目本身都会在本地维护node_modules，CLI工具通过npx调用本地版本，几乎不需要全局装什么。
提示：
npx是Node自带命令，它会优先找当前项目里的依赖。所以即使全局没有一个webpack命令，你在项目目录里照样能npx webpack ...，这能躲开很多全局版本混乱的问题。
6. 关于winvm-windows与同类工具的选择
6.1 几种工具的横向对比
我在Windows上用过的Node版本管理工具有三类：nvm-windows、winvm-windows、volta。三个都能解决双版本问题，但使用体验和适用场景有差异。
| 工具 | 安装复杂度 | 切换速度 | 自动化程度 | 备注 |
|---|---|---|---|---|
| nvm-windows | 中，需要安装器 | 快 | 手动nvm use |
老牌，社区资料多 |
| winvm-windows | 低，解压即用 | 快 | 手动，但结构简单 | 轻量，命令风格接近Linux nvm |
| volta | 中 | 快 | 高，可配置项目版本 | 自动切换，同时管理npm/yarn |
volta的自动切换能力很适合现代项目，但它的“自动”有时候也会让人困惑，比如你明明想临时用别的版本，但它按照工程配置硬切换了。如果你更希望“自己可控”，winvm-windows这种手动切换的更适合。
6.2 我的选择与习惯
我自己现在的习惯是：个人电脑上保留两个Node版本，16和18，按项目切换；如果某台机器需要更多版本，也用同样的方式扩展。工具上用winvm-windows，因为它足够轻，不会在系统里塞一堆服务或计划任务，行为透明，出问题容易排查。
但说实话，工具本身不是重点，重点是你要理解“版本隔离”的机制。我觉得一个合格的Node开发环境，至少要满足三点：能快速切换Node版本；全局包不会互相污染；项目的版本约定能被记录和执行。winvm-windows能让你做到前两点，第三点靠.nvmrc和团队的规范来补。
如果你习惯了自动切换，可以试试volta；如果你更熟悉Linux上的nvm命令，用winvm-windows会很顺手；如果你不想折腾命令行，也许直接官方安装器+手动改路径就够了——但那仅限于偶尔切换，高频使用真不建议。
7. 实测记录与经验补充
7.1 一次完整的迁移过程
最后分享一次我实际迁移的完整过程，算是把上面所有知识串一遍。我的场景是这样的：公司给了一台新Windows笔记本，我需要把Node环境配好，同时要保留16和18两个版本，并且老项目用16、新项目用18。
第一步，先检查系统里有没有旧Node：打开PowerShell，执行node -v，结果显示没有。然后我把winvm解压到D:\tools\winvm，加入用户PATH。
第二步，安装两个版本：
powershell复制winvm install 16.20.2
winvm install 18.20.4
下载过程大概花了几分钟，因为网络源还算顺利。
第三步，激活16并验证老项目。项目里执行node -v确认是16后，npm install、npm run dev都正常。实际上老项目里有些依赖在Node 16下才能编译通过，切到18就是各种报错，但16下很安静。
第四步，激活18并验证新项目。切换、重开终端、node -v确认18，新项目跑起来，原生fetch和AbortController都能用，没有兼容问题。
整个过程不超过二十分钟，主要时间都在下载上。后面我又配置了PowerShell的.nvmrc自动切换，进老项目目录自动用16，进新项目目录自动用18，日常再没手工切过版本。
7.2 一些我没有提到但你需要知道的细节
winvm-windows对Windows 7的支持有限，如果你想在Windows 7上用，建议用旧版Node本身自带的方案或找老版工具，新版winvm可能要求Windows 10+。- Node.js官方的压缩包有些版本解压后是
node.exe直接可执行，不需要安装；winvm实际也是复用这个解压后的运行时，不会修改系统注册表。 - 如果你在公司内网，需要通过代理或内部镜像下载，记得配置
settings.json里的registry，并且确认代理环境变量比如HTTP_PROXY和HTTPS_PROXY是否正确。 - 如果项目里既有
.nvmrc又有package.json的engines字段，以.nvmrc为准做本地切换，以engines作为CI检查依据。
7.3 要不要再多装一个LTS版本
有些读者可能会问：既然装了16和18，要不要顺便装个当前LTS版本，比如20或22？我的看法是，看你实际需求。如果你只是维护旧项目+开发新项目，16和18基本覆盖了大多数存量场景；如果你还要跟进最新的Next.js或者某些只支持Node 18+的新框架，那再加一个20甚至22也不是不行。
winvm-windows不会因为版本装得多而变慢，反正每个版本都是独立目录，占用的也只是磁盘空间。但版本太多容易让人迷失，我建议控制在两到三个版本内，多了反而增加管理成本。
我个人的配置就是16和18两个，偶尔需要Node 20的时候再临时winvm install 20.11.1，用完也不用删，留着不碍事。等到某天老项目彻底升级完，16就不需要保留了，直接winvm uninstall 16.20.2清理掉，非常干净。
根据我目前的经验，还有一点要提醒：装新版本前先看一下这个版本是否已经释放了对应的Windows二进制包。热搜词里就有“Node.js v24.19.0 is not yet released or is not available”这样的错误，意思是你试图安装一个还没发布的版本，或者官方还没提供对应平台的压缩包。用winvm install前可以先winvm list available查一下可选版本，别凭记忆输版本号。
写到这儿，我在Windows上同时使用Node.js 16和18的这套流程已经完整走了一遍。winvm-windows虽然在社区里不算最热门，但胜在轻量和透明，我用了很长一段时间没有出过岔子。你如果也面临老项目和新项目版本打架的情况，可以照着我上面的步骤试一次，装好之后让工具替你做版本切换，自己把精力花在真正写业务代码上。