VSCode需终端环境与调试器配置双路协同才能正确切换Node版本：终端须启用terminal.integrated.inheritEnv为true并加载nvm，调试器需在launch.json中设"runtimeExecutable": "${env:NVM_BIN}/node"。
VSCode 本身不自动感知项目所需的 Node 版本，必须靠终端环境 + 调试器显式配置双路协同才能生效。只配终端或只配调试器，都会漏掉一半场景。
终端里 node -v 对了，但 F5 调试还是旧版本？
这是因为 VSCode 调试器（type: "node"）默认不读终端的 PATH 或 NVM_BIN，它启动时只查自己启动那一刻的环境变量快照。
- 必须在项目根目录的
.vscode/launch.json中显式指定"runtimeExecutable": "${env:NVM_BIN}/node" - 前提是
NVM_BIN真的存在：在集成终端里运行echo $NVM_BIN，有输出才有效；没输出说明 VSCode 启动时根本没加载 nvm - 验证是否生效：F5 启动后，在代码里加
console.log(process.version)，看输出是否匹配预期版本 - 硬编码路径如
"runtimeExecutable": "/Users/x/.nvm/versions/node/v18.19.0/bin/node"不可移植，换机器就崩
新开终端还是用系统自带 node？检查 shell 初始化是否被跳过
VSCode 集成终端默认不是 login shell，~/.zshrc 或 ~/.bash_profile 里的 nvm 初始化逻辑（source ~/.nvm/nvm.sh）压根不会执行。
- macOS/Linux：在 VSCode 设置中搜
terminal.integrated.inheritEnv，设为true，然后**完全退出 VSCode（不只是关窗口）再重开** - 或者手动在
settings.json中补全环境变量："terminal.integrated.env.zsh": { "NVM_DIR": "/Users/you/.nvm", "PATH": "/Users/you/.nvm/bin:${env:PATH}" } - Windows：PowerShell 需确保
$PROFILE里有Import-Module "$env:USERPROFILE\.nvm\nvm.ps1"，且 VSCode 终端 profile 设为 PowerShell - 验证：新开终端后运行
which nvm和nvm current，两者都应有合理输出
想打开项目就自动切版本？别依赖“自动”，要靠 .nvmrc + 手动触发或插件
VSCode 不原生读 .nvmrc，nvm 本身也不自动执行 nvm use——这个文件只是个声明，没人读它就等于不存在。
- 最轻量做法：在项目根目录放
.nvmrc，内容写死版本号，如v16.20.2；然后每次打开项目后，在终端手动跑一次nvm use - 省事一点：装插件
vsc-nvm，它会在 VSCode 启动终端时自动检测并执行nvm use（注意：仅对新打开的终端生效，已存在的终端需重启） - Volta 用户注意：Volta 不支持
.nvmrc写范围（如^18），只能用具体版本或别名（lts），且必须先运行volta pin node@18.19.0生成.node-version - 别指望“打开文件夹就静默切换”——所有方案都依赖终端进程重载或插件 hook，没有零配置的魔法
多个项目同时开，Node 版本互相污染？用 Dev Container 隔离最稳
当项目数量多、版本跨度大（比如 v14 和 v20 并存），nvm 切换容易手抖，且所有终端共享同一份 NVM_BIN，本质仍是单环境模拟多环境。
- Dev Container 是真隔离：每个项目运行在独立 Docker 容器里，
node -v、npm、全局模块互不影响 - 操作路径：安装
Dev Containers插件 → 打开项目 → 左下角点击> → <code>Reopen in Container→ 选 Node.js 模板并指定版本 - 容器内仍可用
nvm微调，但宿主机完全无感；调试器天然走容器内环境，不用额外配runtimeExecutable - 代价是首次启动慢、占用内存略高，但换来的是确定性——这点开销对现代机器几乎可忽略
真正麻烦的从来不是“怎么配”，而是搞清哪一层负责哪件事：终端决定 node 命令行为，launch.json 决定调试器行为，.nvmrc 只是数据声明，而 Dev Container 直接绕过所有环境变量博弈。选哪种，取决于你愿不愿意为确定性多点几下鼠标。
