VSCode中Node.js版本切换失效的根本原因是nvm未被终端正确加载或环境变量未继承；需确保Shell配置文件（如~/.zshrc）正确配置nvm，配合.nvmrc文件和vsc-nvm插件实现项目级自动切换，并在launch.json中显式指定runtimeExecutable路径。
VSCode里Node.js版本切不生效，根本不是VSCode的问题，而是nvm没被终端正确加载，或者当前终端会话压根没继承环境变量。
nvm install 和 nvm use 为什么在VSCode终端里不生效
你在系统终端（如iTerm、Terminal.app或PowerShell）里能正常使用 nvm use 18.17.1，但一进VSCode内置终端就报错 command not found: nvm 或者 node -v 仍是旧版本——这说明VSCode终端启动时没读取你的Shell配置文件（比如 ~/.zshrc 或 ~/.bash_profile）。
- VSCode默认用登录Shell启动终端，但某些系统（尤其是macOS Catalina之后）默认Shell是zsh，而你可能把nvm配置写在了
~/.bashrc里，它不会被zsh自动加载 - Windows上用nvm-windows时，VSCode终端若以非管理员权限启动，可能无法访问nvm安装路径（如
D:\nvm），导致nvm命令不可用 - 即使nvm可用，
nvm use的效果只作用于当前shell进程；VSCode新开的终端标签页是全新进程，不会继承上一个终端的node版本
项目级自动切换：.nvmrc + vsc-nvm 插件
靠手动敲 nvm use 不现实，尤其当你同时开十几个Node项目时。真正靠谱的做法是让VSCode“感知到项目需要什么版本”，并在打开终端时自动执行切换。
- 在项目根目录创建
.nvmrc文件，内容只有一行，比如：16.20.2或v18.17.1（带v前缀也可，nvm能识别） - 安装VSCode插件
vsc-nvm（作者：klaussinani），它会在你打开终端时自动检测当前目录下的.nvmrc并运行nvm use - 插件启用后，新打开的终端第一行通常会显示
Now using node v16.20.2 (64-bit)，说明已生效 - 注意：插件只影响终端，不影响VSCode调试器（
launch.json）或任务（tasks.json）——这些仍需单独确认是否用了正确的node路径
调试和任务仍用旧版本？检查 launch.json 的 runtimeExecutable
即使终端里 node -v 正确，VSCode调试时仍可能报错“require Node.js >= 18”，这是因为调试器默认用系统PATH里的node，而不是当前终端激活的版本。
- 在项目
.vscode/launch.json中，给配置加上runtimeExecutable字段，指向nvm管理的实际node路径，例如："runtimeExecutable": "/Users/you/.nvm/versions/node/v18.17.1/bin/node" - 更稳妥的方式是用
nvm which 18.17.1获取当前激活路径，复制粘贴过去，避免硬编码 - 如果项目用了TypeScript或Babel，也要检查
tasks.json中的command是否明确指定了node路径，否则可能调用到全局旧版本
多项目并存时，nvm list 和 nvm current 容易误判
nvm list 显示所有已安装版本，nvm current 显示“当前shell”所用版本——但它不反映VSCode里每个工作区的真实状态。你可能在A项目终端里 nvm use 16，又在B项目终端里 nvm use 20，但 nvm current 只返回最近一次切换的结果，对跨终端场景无意义。
- 不要依赖
nvm current判断某个项目是否正确加载了版本；始终用which node和node -v在对应终端里验证 -
nvm alias default 18.17.1可设全局fallback版本，但仅当没有.nvmrc时才生效，不能替代项目级配置 - Windows用户注意：nvm-windows的
nvm which返回的是符号链接路径（如C:\Program Files\nodejs\node.exe），实际指向nvm管理的版本，但该路径可能被杀毒软件拦截，导致调试失败
最麻烦的地方不在安装nvm，而在确保每次打开终端、启动调试、运行脚本时，调用的都是同一个node二进制文件——它必须来自nvm管理的版本，且路径不能被缓存、别名或环境变量污染。哪怕漏掉 launch.json 里的一行配置，都可能让整个切换逻辑失效。
