VSCode 不管理 Node.js 版本，依赖本地工具（如 nvm）；终端与调试器版本不一致主因是环境变量未同步，需确保 shell 配置加载 nvm 并通过 .nvmrc + nvm use 统一版本。
VSCode 本身不管理 Node.js 版本，真正起作用的是你本地的 Node.js 版本管理工具（如 nvm、fnm 或 volta），VSCode 只负责识别并使用它——所以“配置版本化控制”的核心不在 VSCode 设置里，而在终端环境与工作区集成是否一致。
为什么 VSCode 终端里 node -v 和调试器里不一样？
这是最常踩的坑：VSCode 启动时读取的是系统 shell 的环境变量（比如 ~/.zshrc 或 ~/.bash_profile），但如果你用 nvm use 18.18.2 临时切换过版本，这个状态不会自动同步到 VSCode 新开的集成终端，除非你显式重载或重启窗口。
- 检查当前终端是否已加载
nvm：运行which nvm，返回空说明没生效 - 确保
nvm初始化代码（通常是一段export+source）写在 shell 配置文件末尾，且 VSCode 启动方式能读到它（macOS 下推荐用code --new-window从终端启动） - VSCode 调试器默认继承父进程环境，但若你手动设置了
"runtimeVersion"字段，它会覆盖终端行为——这点容易被忽略
launch.json 中的 runtimeVersion 到底有没有用？
有，但仅限于 VSCode 自带的 Node.js 调试器（node 类型 launch 配置），且只影响调试进程的 Node 版本，不影响终端、任务或扩展（如 ESLint、TypeScript Server）。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 设为
"runtimeVersion": "18.18.2"时，VSCode 会尝试调用nvm exec 18.18.2 node（Linux/macOS）或对应 Windows 脚本 - 如果
nvm不在$PATH，或目标版本未安装，调试直接失败并报错：Cannot find module 'nvm' - 该字段对
npm run dev这类通过终端执行的脚本完全无效——它只管 debugger 进程
如何让整个工作区（终端 + 调试 + 任务）统一用指定 Node 版本？
靠 .nvmrc + 手动触发 nvm use 是最轻量、兼容性最好的方式，不需要 VSCode 插件介入。
- 在项目根目录新建
.nvmrc，内容只有一行：18.18.2 - 打开集成终端后，先运行
nvm use（它会自动读.nvmrc）；可配成 VSCode 启动任务，在tasks.json里加一个shell类型任务执行该命令 - 验证是否生效：在终端里依次运行
node -v、which node、echo $PATH，三者应指向nvm管理的路径（如~/.nvm/versions/node/v18.18.2/bin/node） - 避免混用
volta或fnm：它们的.tool-versions或.node-version文件互不识别，选一个工具并坚持用到底
真正麻烦的不是配置本身，而是不同环节读取环境的方式不一致——终端靠 shell 初始化，调试器靠 runtimeVersion 或 nvm exec，任务靠 tasks.json 显式调用。一旦某个环节漏掉 nvm use，就可能跑在旧版本上，而错误往往只在特定 API（比如 fetch、stream.pipeline）或依赖（如 sharp）里才暴露出来。
