不用反复 nvm use 了：nvm-windows 2.x 按项目自动切换 Node.js
项目 A 用 Node.js 16，项目 B 用 Node.js 22。以前在 Windows 上来回开发，切换项目后还得记得执行一次 nvm use。项目一多，就容易忘记当前命令会用哪个版本。
从 nvm-windows 1.1.12 升级到 2.0.1 后，我最直观的感受是：项目里配置好 .nvmrc，运行命令时就能自动使用对应的 Node.js 版本，不用再反复执行 nvm use <版本号>。
这也解决了我不同项目之间的运行和 commit 提交问题。这篇先看自动切换的实测效果，再介绍如何开启，以及它为什么能影响提交时的检查脚本。
本文记录于 2026 年 10 月 10 日，使用 Windows 版 nvm-windows 2.0.1。下文的 project-a、project-b 是用于验证的示例目录，Node.js 版本按已有环境选取。
1. 先看效果：同一个终端，两个项目自动使用不同版本
我在两个临时目录里分别放入 .nvmrc，内容为 16.20.2 和 22.17.0。两个版本都已安装，当前启用了 shim 模式和 auto_use。
下面省略具体路径，在同一个 PowerShell 会话中执行：
powershell
cd .\project-a
node -p 'process.version'
# v16.20.2
cd ..\project-b
node -p 'process.version'
# v22.17.0两次输出都与项目各自的 .nvmrc 一致，中间没有执行 nvm use <版本号>。
| 操作 | 之前的使用方式 | 现在的使用方式 |
|---|---|---|
| 进入另一个项目后运行命令 | 先手动选择 Node.js 版本 | 根据项目配置自动选择 |
| 维护项目的版本要求 | 查看约定，再执行切换命令 | 将版本写入 .nvmrc |
| 检查当前项目的实际运行版本 | 运行 node -v |
仍然可以运行 node -v 验证 |
这里的"自动切换"，具体指 执行命令时按项目解析版本 。cd 负责进入目录，随后运行的 node 等命令通过 shim 选择对应版本，不需要每次修改共享的默认版本。官方配置说明
2. 以前为什么总要手动执行 nvm use？
先看一个常见场景：
| 项目 | 约定的 Node.js 版本 |
|---|---|
| project-a | 16.20.2 |
| project-b | 22.17.0 |
这里用 Node.js 16 演示旧项目的兼容需求；新项目应根据依赖支持情况选择仍受维护的版本。
在旧版 nvm-windows 中，一般需要手动执行：
powershell
nvm use 16.20.2切到另一个项目，再执行：
powershell
nvm use 22.17.0旧版通过修改共享的 Node.js 符号链接来切换版本。多个终端如果使用同一个链接入口，之后启动的 Node.js 命令就可能受到这次切换影响。已经运行的 Node.js 进程则不会因此换成另一个版本。
所以，电脑里装了多个版本，解决的是"有哪些版本可用"；每个项目执行命令时用哪个版本，还需要另外处理。旧版 nvm-windows 说明
3. .nvmrc：让自动切换知道项目需要哪个版本
.nvmrc 是一个记录项目 Node.js 版本的文本文件，通常放在项目根目录，例如：
text
22.17.0文件本身不会执行切换操作，需要工具读取它。不同平台上名字都叫 nvm 的工具，支持情况也不同。
| 使用环境 | .nvmrc 的作用 |
|---|---|
| macOS/Linux 的 nvm | 不带版本参数执行 nvm use 时，可以读取文件中的版本 |
| 我原来的 nvm-windows 1.1.12 | 不原生提供基于 .nvmrc 的项目自动切换，需要手动指定版本或配合脚本 |
| nvm-windows 2.0.1 的 shim 模式 | 可以在执行命令时根据项目配置选择 Node.js 版本 |
因此，以前这个文件仍然能为团队成员、CI 配置或辅助脚本提供版本约定。只是我原来的 Windows nvm 不会自动按它执行。
另外，macOS/Linux 的 nvm 支持读取 .nvmrc，也不等于默认在 cd 时自动切换；后者通常还需要 Shell 集成。nvm 的 .nvmrc 文档、Windows 旧版命令说明
4. 自动切换是怎么实现的？认识 shim 模式
自动按项目选择版本，依赖的是 shim 模式下的项目版本识别。
可以把 shim 理解为命令入口处的一层转发程序：运行 node 等命令时，它先解析项目需要的版本，再调用对应的可执行文件。
text
项目目录中的命令
↓
nvm 的 shim 入口
↓
读取项目版本配置
↓
调用对应版本的 Node.js这个机制发生在命令执行时，不依赖给 cd 命令额外安装一个自动切换脚本。2.x 仍提供 link 模式；要使用这里讨论的自动识别能力，需要确认当前采用 shim 模式。官方模式说明
项目配置除了 .nvmrc，还可以使用 .node-version、package.json 中的 engines.node 等。本文统一使用 .nvmrc，方便直接看出项目选择了哪个版本。版本解析说明
5. 开启自动切换：升级、检查配置、添加 .nvmrc
这次使用的是 2.0.1 官方发布页 中的 Windows x64 安装器。
升级前，先记录当前环境：
powershell
nvm version
nvm list
node --version
npm --version我还备份了原来的 nvm 配置、Node.js 安装目录及其中的全局包文件。官方安装器支持从 v1 迁移到 v2，旧的 v1 更新器则不适用于这次跨大版本升级。官方安装说明
迁移后，原有 7 个 Node.js 版本均保留，各版本文件数量及 node.exe 哈希与备份一致。默认 Node.js 仍为 v22.17.0，对应 npm 为 10.9.2。
这里还有一个实际遇到的问题：安装器完成后，PATH 没有正确指向新版入口，导致普通终端暂时找不到 nvm 和 npm。修复旧路径残留、补上新版入口后，命令才恢复正常。
所以，看到安装完成提示后，还需要重新打开终端验证。如果使用 IDE 内置终端或图形化 Git 提交，也要重启 IDE，让它重新读取环境变量。
升级完成后，检查自动切换所需的配置：
powershell
nvm config get mode auto_use auto_install我这次的实际输出是：
text
mode: shim
auto_use: true
auto_install: false如果尚未启用，可以执行：
powershell
nvm use shim
nvm config set auto_use=trueauto_use 控制是否按项目配置使用版本；auto_install 控制是否自动安装缺失版本。我的环境保留了 auto_install=false，因此应提前安装项目需要的 Node.js。配置文档
接着，在两个项目中分别添加 .nvmrc：
text
project-a/
└── .nvmrc 内容为 16.20.2
project-b/
└── .nvmrc 内容为 22.17.0配置好后，按文章开头的方式，在两个目录分别运行 node -p 'process.version'。这比单独运行 nvm list 更直接：版本列表只能说明装了哪些版本，而 process.version 能说明当前项目实际启动了哪个版本。
实际项目还可以检查可执行文件路径：
powershell
node -p 'process.execPath'确认后，把 .nvmrc 纳入 Git 管理，让版本要求跟着项目走。示例使用完整版本号，便于复现环境；项目已有版本约定时，先保持约定一致。
6. 自动选对 Node.js，也能改善 commit 提交体验
这次升级后，我不同项目之间的 commit 问题也得到了解决。理解这个变化，需要看提交时实际执行了什么。
Git 本身不依赖 Node.js，但前端项目的 Git Hooks 经常会调用 Node.js 工具。以常见的 Husky 配置为例，提交时可能运行 lint-staged、ESLint 或 commitlint。
text
git commit
↓
pre-commit / commit-msg
↓
检查脚本或前端工具
↓
Node.js 运行环境如果这些脚本拿到了不兼容的 Node.js 版本，或者图形化 Git 客户端的 PATH 找不到命令，提交就可能失败。Husky 官方文档也专门说明了版本管理器与 GUI 环境中的 PATH 问题。Husky 文档
在 shim 能被找到、钩子工作目录能识别到项目版本配置的前提下，钩子调用的 Node.js 工具也可以使用对应项目的版本。这是新版机制能够改善提交体验的原因。
如果升级后仍然提交失败，可以在已有 hook 中临时添加下面两行，检查它的执行目录和 Node.js 环境，定位完成后删除：
sh
pwd
node -p 'JSON.stringify({ version: process.version, execPath: process.execPath })'hook 通常由 Shell 执行，所以这里使用 Shell 命令；前面的环境检查示例使用 PowerShell。
7. 自动切换没有生效？先检查这几个地方
我会先确认四件事：
- 当前是否为 shim 模式，
auto_use是否开启。 .nvmrc中指定的版本是否已经安装。- 终端或 IDE 是否已经重启，实际命令入口是否正确。
- 执行命令的目录能否找到项目版本配置，脚本有没有硬编码旧的 Node.js 路径。
在 Windows 中，命令入口可以这样检查：
powershell
where.exe nvm
where.exe node
where.exe npm如果出现多个结果，要结合 node -p 'process.execPath' 判断实际使用的是哪一个。不要直接清空 PATH，只处理确认失效或发生冲突的条目。
另外，Node.js 版本匹配后，项目仍可能因为包管理器版本、依赖安装状态或检查规则不通过而报错。这时继续查看具体日志，比反复切换 Node.js 更有效。
现在切换项目，我只需要进入对应目录，照常运行项目命令。.nvmrc 记录版本要求，shim 在执行时选择对应的 Node.js。对每天来回维护多个项目的我来说，少掉的正是那一步反复执行、又容易忘记的 nvm use。