launch.json的env字段不支持加载多个.env文件，仅支持单个envFile路径或手动键值对；多文件需在代码中用dotenv按顺序加载，且env字段值优先级最高，会无条件覆盖envFile和系统环境变量。
launch.json里env字段怎么加载多个.env文件
VSCode的launch.json本身不支持直接“加载多个.env文件”，它只认env对象里手写的键值对，或通过envFile字段指定**单个**文件路径。想实现分级覆盖（比如.env + .env.development），得靠代码层处理，不是调试器的事。
常见错误是以为在envFile里写数组或逗号分隔路径就能生效——实际会报错或静默忽略。
- 正确做法：在项目入口文件（如
app.js）开头用dotenv手动加载多文件，顺序即覆盖优先级：require('dotenv').config(); // .env require('dotenv').config({ path: '.env.development' }); // 后加载的覆盖前一个 -
launch.json中只配"envFile": ".env"即可，别试图塞多个；真正需要分级覆盖时，把逻辑交给dotenv而不是VSCode - 注意
dotenv默认不递归合并，重复key会被后加载的文件覆盖，不是深合并
调试时环境变量被覆盖的优先级在哪一层
VSCode调试器里环境变量有明确的三层覆盖关系，从高到低依次是：
-
launch.json里的env字段 —— 最高优先级，硬编码值直接覆盖一切 -
launch.json里的envFile—— 中等，加载的文件内容会注入到进程环境，但会被上面那层覆盖 - 系统/Shell环境（如
$NODE_ENV）—— 最低，仅当launch.json里没定义同名变量时才生效
例如你在envFile里写了NODE_ENV=production，但在launch.json的env里又写了"NODE_ENV": "development"，最终进程看到的一定是development。
远程调试时还多一层：远程服务器本身的shell环境变量，优先级低于launch.json但高于本地系统变量。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
不同环境配置如何避免launch.json被覆盖或误用
多人协作或CI/CD场景下，launch.json容易被误提交或覆盖。关键不是“防覆盖”，而是“分层隔离”：
- 把通用配置（如
program、type）放在.vscode/launch.json，但env部分留空或只写安全默认值（如"NODE_ENV": "development"） - 敏感或环境特有变量（如
API_KEY、DB_URL）绝对不写进launch.json，改用.env.local配合dotenv加载 - 用
gitignore明确忽略.vscode/launch.json——它本就是个人调试配置，不该进版本库 - 团队统一约定：所有环境变量由
.env.*文件管理，launch.json只负责启动行为（端口、入口文件、是否attach），不承担配置职责
为什么process.env里看不到shell里export的变量
因为VSCode调试器启动Node进程时，压根不读你的shell初始化文件（.zshrc、.bash_profile），它只认launch.json和envFile。
典型现象：echo $MY_VAR在终端里有输出，但console.log(process.env.MY_VAR)是undefined。
- 解决方法只有两个：要么在
launch.json的env里显式写进去，要么在envFile里定义 - 别指望
terminal.integrated.inheritEnv能带过来——它只影响集成终端，不影响F5启动的调试进程 - 如果变量来自nvm或rbenv这类版本管理器，更要小心：
$NVM_BIN在终端里可用，但调试器里必须用${env:NVM_BIN}引用，且前提是VSCode启动时已加载了nvm（见前文配置）
真正麻烦的从来不是“怎么加变量”，而是搞清哪一层在起作用、哪一层被忽略了。变量没生效，先看launch.json里有没有同名env项，再查envFile路径对不对，最后才轮到shell环境——顺序错了，调三天也白搭。
