vscode本身不隔离node.js版本，需手动对齐终端、调试器、shell初始化和工作区四层配置；漏配任一层即导致node -v与f5调试版本不一致，核心在于环境变量加载时机与作用域隔离。
VSCode 本身不隔离 Node.js 版本，所谓“为新项目单独配 Node 环境”，本质是手动把 nvm 的当前版本、终端 PATH、调试器启动路径、工作区设置四层对齐——漏一层，node -v 和 F5 就不一致。
终端里 nvm 不生效？先确认是不是 login shell
VSCode 集成终端默认不是 login shell，所以 ~/.zshrc 或 ~/.bash_profile 里的 source ~/.nvm/nvm.sh 根本不执行。现象是：which nvm 返回空，echo $NVM_BIN 为空。
- 在 VSCode 设置中搜
terminal.integrated.inheritEnv，设为true，然后完全退出 VSCode（关窗口不算）再重开 - 或者直接编辑
settings.json，补全环境变量：
"terminal.integrated.env.zsh": {
"NVM_DIR": "/Users/you/.nvm",
"PATH": "/Users/you/.nvm/bin:${env:PATH}"
}
新开终端后立刻验证：nvm current 应输出版本，which node 应指向 ${NVM_BIN}/node。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
F5 调试仍用旧版 Node？launch.json 必须显式引用 $NVM_BIN
VSCode 调试器启动时只读取启动那一刻的环境快照，它完全不继承终端的 PATH 或 NVM_BIN。所以终端里 node -v 是 v18.19.0，F5 却跑 v16.20.2，非常正常。
- 项目根目录下确保有
.vscode/launch.json - 必须写入
"runtimeExecutable": "${env:NVM_BIN}/node"，不能省略${env:NVM_BIN} - 硬编码路径如
/Users/x/.nvm/versions/node/v18.19.0/bin/node看似能用，但换机器或重装 nvm 就失效 - 前提：上一步终端已确认
$NVM_BIN非空，否则${env:NVM_BIN}展开为空，调试器会 fallback 到系统默认node
多个项目同时开，怎么让它们用不同 Node 版本？靠工作区级 settings.json
只靠全局设置或 shell profile，无法让 frontend/ 和 backend/ 各自用不同 Node 版本——它们共享同一套终端初始化逻辑，除非你把环境加载逻辑下沉到每个项目内部。
- 在项目根目录下创建
.vscode/settings.json - 写入对应版本的 nvm 初始化指令（比如
nvm use 18），并配合上面的terminal.integrated.env.*配置 - VSCode 工作区设置优先级高于全局，但注意：它只影响该文件夹下的终端和调试器，不改变系统 shell 行为
- 如果项目依赖
package.json中的engines.node字段，可配合nvm install+nvm alias做版本绑定，但需手动触发
真正麻烦的从来不是配置项本身，而是四层之间的时间差和作用域隔离：终端环境变量加载时机、调试器快照捕获点、工作区设置生效范围、以及 nvm 当前版本是否真的被 shell 解析到了——这些细节一旦错位，node -v 和实际运行环境就永远对不上。
