VSCode终端nvm use不生效，因默认非登录shell未加载~/.zshrc等配置：macOS/Linux需将nvm初始化代码移至~/.zsh_profile（或~/.bash_profile），并设terminal.integrated.defaultProfile中shell的args为["-l"]；Windows需手动补PATH或从终端启动code；tasks/launch需显式配置NVM_BIN路径。
VSCode 终端里 nvm use 不生效？先确认它是否被加载
VSCode 集成终端默认不是 login shell，~/.zshrc 或 ~/.bashrc 里的 nvm 初始化逻辑（比如 source ~/.nvm/nvm.sh）根本不会执行。所以你敲 nvm use 18.19.0 报错 “command not found”，不是没装 nvm，而是终端压根不认识它。
- 在 VSCode 终端运行
which nvm，没输出就说明 nvm 没加载 - 检查你的 shell 初始化文件：
zsh用户看~/.zsh_profile（login shell 读这个），bash用户看~/.bash_profile - 把 nvm 初始化代码（通常是
export NVM_DIR=... && [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"）挪进去，而不是留在~/.zshrc - 改完后**完全退出 VSCode（不只是关窗口）再重开**，否则环境变量不刷新
终端能用 nvm 了，但 node -v 还是旧版本？别跳过 -l 参数
即使 nvm 命令可用，nvm use 也可能不生效——因为 VSCode 默认启动的是非 login shell，而 nvm 的 auto-use 机制（自动读 .nvmrc）只在 login shell 下触发。
- 打开 VSCode 设置（
Cmd+,），搜索terminal.integrated.defaultProfile - 找到你用的 shell（如
zsh），点击“在 settings.json 中编辑” - 添加或修改
args字段："args": ["-l"]—— 这个-l表示以 login shell 启动 - 确保项目根目录有
.nvmrc（内容就一行，比如18.19.0），新终端打开时才会自动执行nvm use
tasks.json 或调试器仍跑错 Node 版本？环境变量不跨进程传递
你在终端里 nvm use 18.19.0 成功了，node -v 也对了，但 tasks.json 里跑 npm run dev 或 F5 调试还是用系统自带的 Node（比如 v16），这是因为 task 和调试器启动时不走 shell，不读 PATH，也不继承你手动设置的环境变量。
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 在
.vscode/launch.json里必须显式配"runtimeExecutable": "${env:NVM_BIN}/node" - 验证
NVM_BIN是否有效：在 VSCode 终端里运行echo $NVM_BIN，有输出才说明 nvm 已激活 -
tasks.json中避免写死路径，改用"options": { "env": { "PATH": "${env:NVM_BIN}:${env:PATH}" } }注入环境 - 硬编码绝对路径（如
/Users/x/.nvm/versions/node/v18.19.0/bin/node）会导致项目无法共享或换机器失效
插件能省事，但别指望它“全自动”
像 vsc-nvm 这类插件确实能在新终端打开时自动检测 .nvmrc 并执行 nvm use，但它只对新开终端生效，已存在的终端不会刷新，也不会影响 task 或调试器。
- 插件不是魔法：它依赖终端能调用
nvm，所以前面两步（nvm 加载 + login shell）仍是前提 -
.nvmrc文件必须放在项目根目录，且内容只能是具体版本号（如18.19.0）或别名（如lts），不能写^18或~18.0.0 - Volta 用户注意：
.nvmrc对 Volta 无效，得用volta pin node@18.19.0生成.node-version
真正容易被忽略的点是：VSCode 启动那一刻的环境快照决定了所有后续子进程（task、debugger、甚至某些扩展）能拿到什么，不是终端里“看起来对了”就万事大吉。
