VSCode调试器不继承终端环境变量，必须在launch.json中配置"runtimeExecutable": "${env:NVM_BIN}/node"并确保NVM_BIN有效；同时需启用terminal.integrated.inheritEnv为true并彻底重启VSCode。
终端里 node -v 正确但 F5 调试用错版本
这不是 nvm 没切成功，而是 VSCode 调试器根本没读终端的环境。它启动时只认自己启动那一刻的 PATH 快照，nvm use 18.18.2 的效果不会自动同步过去。
- 必须在项目根目录的
.vscode/launch.json中显式配置："runtimeExecutable": "${env:NVM_BIN}/node" - 先验证
NVM_BIN是否有效：在集成终端运行echo $NVM_BIN，有输出才说明 nvm 已加载 - 如果
${env:NVM_BIN}展开为空，调试会直接报Cannot resolve runtimeExecutable -
runtimeVersion字段只对type: "node"的 launch 配置生效，且依赖nvm exec，不适用于npm run dev等终端任务
VSCode 集成终端始终用系统自带 node
常见原因是 VSCode 启动时没加载 shell 配置（如 ~/.zshrc），导致 nvm 命令不可用、NVM_DIR 未设、PATH 没更新。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 打开设置搜
terminal.integrated.inheritEnv，设为true—— 改完必须完全退出 VSCode（不是关窗口），再重开 - macOS/Linux 下，确认
~/.zshrc（或对应 shell 配置）末尾有 nvm 初始化代码，且路径正确：export NVM_DIR="$HOME/.nvm"+[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" - 验证是否生效：新开终端后运行
which nvm和nvm current，两者都应返回合理结果 - Windows 用户注意：
nvm-windows不设NVM_BIN，要用"runtimeExecutable": "${env:USERPROFILE}\.nvm\v18.18.2\node.exe"这类硬编码（不推荐跨机器）
想打开项目就自动切 Node 版本
.nvmrc 文件本身不会被 VSCode 或 nvm 自动触发 —— 它只是个声明，没人执行 nvm use 就等于不存在。
- 最轻量做法：项目根目录放
.nvmrc，内容只有一行，比如18.18.2；每次打开项目后，在终端手动运行一次nvm use - 省事方案：装插件
vsc-nvm，它会在新终端启动时自动检测并执行nvm use（已存在的终端需重启才生效） - 别用
volta或fnm混搭：它们的.tool-versions或.node-version与.nvmrc互不识别，选一个工具坚持用到底 - 避免写
^18或lts在.nvmrc里：nvm 只认具体版本号或别名（如lts/hydrogen），volta才支持范围语法
验证整个工作区是否真正统一
终端、调试器、任务、ESLint、TypeScript Server 都可能各自读取不同环境，只看 node -v 不够。
- 在终端运行三句命令：
node -v、which node、echo $PATH—— 三者应指向 nvm 管理的同一路径，比如~/.nvm/versions/node/v18.18.2/bin/node - F5 启动后，在代码里加
console.log(process.version, process.execPath)，确认输出和which node一致 - 如果 ESLint 报错
ESLint couldn't determine the version of Node.js，说明它没走 nvm 环境，需在 VSCode 设置里指定 ESLint 的 Node 路径：eslint.nodePath设为${env:NVM_BIN} - 真正麻烦的是环节割裂：终端靠 shell 初始化，调试器靠
runtimeExecutable，任务靠tasks.json显式调用 —— 没有“一键全同步”，只有分层控制
