最稳定的方式是在 launch.json 中为每个环境创建独立 configuration。env 必须是全大写下划线命名的对象，避免硬编码敏感值，node_env 大小写需严格匹配，env 与 args 用途不可混淆，注意跨平台路径和变量替换兼容性。
直接在 launch.json 里为每个环境建一个独立配置，是最稳定、最易排查的方式。硬编码 env 字段比依赖外部 .env 文件或运行时读取更可靠——调试启动那一刻变量就必须就位，不能等代码去加载。
用多个 configurations 显式定义开发/测试/生产环境
VSCode 调试器不支持“运行时切换环境”，只支持启动时选一个配置。所以别试图在一个配置里用条件逻辑判断环境，而是把不同环境拆成多个并列的 configuration 对象：
- 每个
name值要能一眼区分用途，比如"Dev Server"、"Test API Client"、"Prod Simulation" -
env字段必须是对象（不是数组），键名全大写、下划线分隔，值字符串不要带空格或特殊字符 - 避免在
env里写敏感值（如密钥），改用${env:MY_API_KEY}引用系统级环境变量，或通过inputs动态输入 - Node.js 项目中，
process.env.NODE_ENV的值必须和env.NODE_ENV完全一致（包括大小写），否则框架（如 Express、Next.js）可能忽略配置
env 和 args 别混用，用途完全不同
env 注入的是操作系统级环境变量，进程内任何地方都可通过 process.env（Node）、os.environ（Python）访问；args 是命令行参数，只对 program 入口文件的 argv 生效。常见错误是把本该进 env 的 API_BASE_URL 塞进 args，导致代码里要用 argv.find(x => x.startsWith('--api-url=')) 解析，徒增复杂度。
- 该走
env的：配置标识（NODE_ENV）、服务地址（DB_HOST）、开关标志（ENABLE_FEATURE_X） - 该走
args的：临时覆盖参数（--port 4000）、一次性指令（--migrate-only）、CLI 工具特有的选项 - 如果两者都要传，确保
args不会意外覆盖env行为（例如某 CLI 工具把--env production解析成内部变量，和env.NODE_ENV冲突）
跨平台路径和变量替换容易出错
Windows 和 macOS/Linux 对路径分隔符、大小写、空格处理不一致。${workspaceFolder}/src/app.js 在 Windows 上可能变成 C:\project\src\app.js，但某些调试器（尤其是 C/C++ 的 cppdbg）要求路径用正斜杠且不能有盘符前缀。此时要优先用 ${workspaceFolderBasename} 或 ${fileBasenameNoExtension} 这类安全变量，而不是拼接绝对路径。
-
${env:HOME}在 Windows 上为空，应改用${env:USERPROFILE} -
${file}在未保存文件时返回空字符串，调试会直接失败，务必设program为已存在路径 - 在
env中引用其他变量（如"PORT": "${env:DEFAULT_PORT}"）仅在 VSCode 1.80+ 支持，旧版本会静默忽略
真正麻烦的不是写配置，而是当团队里有人删了 .vscode 目录、或者拉了新分支却忘了同步 launch.json 里的环境字段——这时候程序跑得通，但调试时 process.env 少了关键项，问题会藏得很深。建议把常用环境配置片段存成代码片段（snippets），而不是靠记忆手敲。
