VSCode调试器使用启动时缓存的PATH而非当前终端环境，需勾选terminal.integrated.inheritEnv并完全重启VSCode，再配置launch.json中"runtimeExecutable": "${env:NVM_BIN}/node"。
VSCode 重启才生效，不是 nvm 没切成功，而是 VSCode GUI 进程压根没加载你的 shell 初始化逻辑。 它启动时固化了一套环境变量（包括 PATH 和 NVM_BIN），后续你在终端里执行 nvm use 不会影响已启动的调试器或任务进程。
为什么终端里 node -v 正确，但 F5 调试还是旧版本？
VSCode 的 Node.js 调试器（type: "node"）默认不继承集成终端的环境变量。它直接查启动时缓存的 PATH，而这个 PATH 是 VSCode 启动那一刻从父进程（GUI）继承来的——和你当前终端里 nvm use 的结果无关。
常见现象：
-
which node在集成终端返回~/.nvm/versions/node/v18.17.0/bin/node，但 F5 后process.version打印v16.20.2 - 调试时报错
Cannot find module 'node:fs'（Node.js 16 不支持node:前缀，说明实际跑的是旧版） -
launch.json没配runtimeExecutable，调试器就取PATH里第一个node，通常是系统自带或旧 nvm alias
terminal.integrated.inheritEnv 必须设为 true 并完全重启 VSCode
这是最常被跳过的一步。VSCode 默认不继承 shell 环境，即使你 ~/.zshrc 里写了 source ~/.nvm/nvm.sh，GUI 进程也看不到 nvm 命令。
操作步骤：
- 打开设置（
Cmd + ,），搜terminal.integrated.inheritEnv，勾选启用 - 必须完全退出 VSCode（macOS 上是
Cmd + Q，不只是关窗口），再重开 - 重启后，在集成终端运行
echo $NVM_BIN，确认有输出；再运行nvm current看是否显示预期版本 - 若仍无输出，检查 shell 类型：macOS 默认是
zsh，确保~/.zshrc中有export NVM_DIR="$HOME/.nvm"和[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
launch.json 中 runtimeExecutable 要用 ${env:NVM_BIN}/node
硬编码路径（如 "runtimeExecutable": "/Users/xxx/.nvm/versions/node/v18.17.0/bin/node"）会跨机器失效。可靠写法是依赖环境变量间接指向：
"runtimeExecutable": "${env:NVM_BIN}/node"
但前提是：${env:NVM_BIN} 必须能展开——这又回到上一步：VSCode 必须继承了该变量。验证方式：
- 在集成终端运行
echo $NVM_BIN，有输出才说明变量已就位 -
launch.json中拼写必须准确：env全小写、冒号后空格可选但引号必须闭合、斜杠方向为 Unix 风格 - 如果
${env:NVM_BIN}展开为空，调试器会报Cannot resolve runtimeExecutable
真正卡住人的地方不是配置本身有多难，而是「改完设置不完全退出 VSCode」和「以为 nvm use 能全局生效」这两个动作之间的认知差。环境变量不是广播信号，它只对新进程有效——而 VSCode 的调试器就是那个没收到新信号的老进程。
