vscode本身不锁死node版本，需nvm、.nvmrc与终端/调试器配置协同生效；漏任一环即版本漂移，.nvmrc需配合nvm use或登录shell才触发，调试器仅认launch.json中runtimeexecutable，多项目需工作区级settings.json隔离环境。
VSCode 本身不“锁死”任何 Node 版本，所谓“锁死”其实是靠 nvm + .nvmrc + VSCode 终端/调试器配置三者协同生效的——漏掉任意一环，版本就容易漂移。
VSCode终端不读.nvmrc？它根本不会自动读
.nvmrc 文件（内容如 18.19.0）只对 nvm use 命令生效，VSCode 内置终端默认压根不触发它。你开新终端、执行 node -v，结果还是旧版本，不是 .nvmrc 失效，是它根本没被加载。
- 必须确保 VSCode 终端启动时能执行
source ~/.nvm/nvm.sh—— macOS/Linux 用户在settings.json中设"terminal.integrated.shellArgs": ["-l"]，强制登录 Shell 加载~/.zshrc - Windows 用户需手动补全环境变量：
"terminal.integrated.env.windows": { "PATH": "D:\nvm\v18.19.0;${env:PATH}" }，路径要和nvm current输出一致 - 验证方式：新开终端后直接运行
nvm current，输出必须是你.nvmrc里写的版本；如果报command not found: nvm，说明 shell 初始化失败，后续所有“锁死”都是空谈
launch.json里runtimeExecutable写错，F5就跑偏
VSCode 调试器（F5）完全不看终端当前 node 是哪个，也不读 .nvmrc，它只认 launch.json 里硬写的 runtimeExecutable。哪怕终端里 nvm current 显示 v20.15.0，只要这里写的是 "node" 或空值，它就调用系统默认 Node。
- 正确写法必须是：
"runtimeExecutable": "${env:NVM_BIN}/node"（macOS/Linux）或"runtimeExecutable": "D:\nvm\v20.15.0\node.exe"（Windows） -
${env:NVM_BIN}能用的前提是：上一步终端已成功加载 nvm，且echo $NVM_BIN有输出；否则展开为空，调试器 fallback 到系统 PATH 里的 node - 别用
"node"简写——这等于放弃控制权；也别硬编码绝对路径，换机器或重装 nvm 就失效
多项目并发开，版本怎么不串？靠工作区级 settings.json
全局设置只能保证“VSCode 整体行为一致”，但 frontend 和 backend 两个文件夹需要不同 Node 版本时，必须把环境配置下沉到每个项目内部，否则一个终端切了版本，另一个项目立刻受影响。
- 在项目根目录建
.vscode/settings.json，内容只写终端启动参数："terminal.integrated.shellArgs": ["-l"]（macOS/Linux）或"terminal.integrated.env.windows"（Windows） - 每个项目单独放
.nvmrc，内容写明所需版本（如16.20.2），不要带v前缀 - VSCode 工作区设置优先级高于全局设置，这样打开 frontend 目录时终端自动加载 v16，打开 backend 目录时加载 v20，互不干扰
真正容易被忽略的点是：VSCode 的“重启”必须彻底退出进程（macOS 关窗口不算，Windows 任务管理器里确认 Code 进程消失），否则 shell 初始化逻辑不会重新加载；.nvmrc 不是魔法文件，它只在你主动执行 nvm use 或配合 shell 登录流程时才起作用——没人调它，它就只是个文本。
