VSCode调试时需显式配置envFile或env字段才能加载.env变量，因其调试器不自动调用dotenv且仅按行解析=赋值，不支持注释、多行、占位符或链式加载。
VSCode 调试时不会自动加载 .env 文件，必须显式配置 envFile 或 env 字段，否则 process.env 里根本看不到变量 —— 这不是 dotenv 没起作用，而是 VSCode 根本没把文件喂给 Node 进程。
launch.json 中 envFile 的实际行为
VSCode 的 Node.js 调试器（type: "node"）支持 envFile 字段，但它只在调试启动阶段读取并注入变量，不调用 dotenv 库，也不解析注释或多行值。它只是按行切割 =，简单赋值到进程环境。
-
envFile必须是绝对路径或相对于${workspaceFolder}的路径，写成"./.env"会失败，得用"${workspaceFolder}/.env" - 如果
.env里有API_KEY=sk-xxx，调试时process.env.API_KEY就能拿到；但若用了dotenv-safe的占位符语法（如DB_PASSWORD=${DB_PASSWORD}），envFile完全不处理，直接当字面量塞进去 - 多个
.env文件不能链式加载（比如.env+.env.local），envFile只认一个文件
开发阶段如何安全分级：本地调试 vs 启动脚本
真正需要分级（dev/staging/prod）和敏感信息保护的场景，不能只靠 envFile。它适合本地调试快速验证，但不适用于 CI/CD 或多环境部署。
- 调试时用
envFile加载.env.development，明文存非敏感配置（如PORT=3000） - 启动脚本（如
npm start）应依赖dotenv+dotenv-expand，支持.env→.env.local覆盖，且可读取系统已有变量做插值 - 敏感字段（如
JWT_SECRET）绝不能进 Git，应在远程服务器上通过launch.json的env字段单独传入，或由容器/Docker Compose 注入
为什么 require('dotenv').config() 在调试时不生效？
因为 VSCode 调试器启动 Node 进程前已把 envFile 注入完毕，此时再执行 dotenv.config() 属于“二次加载”，既冗余又可能覆盖掉你从 envFile 里精心配好的变量（比如 dotenv 默认会 override: false，而 envFile 是强制覆盖）。
- 若代码里写了
dotenv.config({ path: '.env.production' })，它会在运行时覆盖调试器注入的process.env，导致变量错乱 - 正确做法：调试时禁用代码里的
dotenv调用（加if (process.env.NODE_ENV !== 'test')判断），或用环境变量开关控制，例如：if (!process.env.VSCODE_DEBUG) - 检查是否生效：在
index.js开头加console.log(process.env.NODE_ENV, process.env.API_URL)，对比终端运行和调试运行的输出差异
远程调试时环境变量的优先级陷阱
远程调试（如 Remote-SSH 或 Attach 模式）下，变量来源有三层：远程 shell 环境、launch.json 的 env、envFile。它们不是合并，而是覆盖关系 —— env 字段最高，envFile 次之，shell 最低。
- 远程服务器上
export NODE_ENV=production，但你在launch.json里写了"env": {"NODE_ENV": "development"}，最终进程看到的是development -
envFile在远程调试中无效（VSCode 不会把本地.env上传到远程），必须改用env字段或确保远程已有对应文件并用dotenv加载 - Linux 远程主机区分大小写，
Db_Password和db_password是两个变量；Windows 下则不区分，容易在跨平台协作时出错
真正麻烦的不是怎么写配置，而是搞清“谁在什么时候、以什么方式、往哪个进程注入了哪些变量”。调试器、终端、Shell、Docker、dotenv 各自有一套规则，混用时变量就消失或被覆盖 —— 多数问题其实发生在边界处，而不是某一行代码错了。
