dotenv默认行为易致加载错误或变量冲突，必须显式指定路径、启用override、校验必需变量并统一类型转换，多环境需用cross-env注入node_env且设兜底逻辑。
dotenv 是开发环境管理敏感变量最轻量、最稳妥的选择，但必须配合路径控制、加载时机和验证机制，否则容易在本地跑通、上线就报错。
为什么不能只写 require('dotenv').config()
默认行为会从 process.cwd() 开始向上查找 .env 文件，一旦项目结构嵌套（比如 CLI 工具调用子包、monorepo 中的 workspace），就可能加载错文件或根本没加载。更危险的是：如果系统已有同名环境变量（如 NODE_ENV=production），dotenv 默认不会覆盖它——你以为读的是 .env.development，实际用的却是系统级的生产值。
必须显式指定路径和覆盖策略：
- 始终用
path.join(__dirname, '../.env')或绝对路径，避免相对路径歧义 - 加
{ override: true }确保 .env 值优先于系统已设变量 - 开发阶段建议开启
{ debug: true }，失败时直接打印错误原因（比如文件不存在、权限被拒）
如何安全地支持多环境（dev/test/prod）而不搞混
靠 NODE_ENV 动态拼接文件名是常见做法，但要注意：这个变量本身也得来自 .env 或命令行，不能靠 process.env.NODE_ENV || 'development' 这种 fallback——万一它为空，就会去读 .env.undefined，静默失败。
推荐做法：
- 用
cross-env在 npm script 里明确注入："dev": "cross-env NODE_ENV=development node index.js" - 入口文件第一行就读取：
require('dotenv').config({ path: `.env.${process.env.NODE_ENV}` }) - 为防
NODE_ENV缺失，加兜底逻辑：const env = process.env.NODE_ENV ?? 'development'; require('dotenv').config({ path: `.env.${env}` })
process.env 里的值永远是字符串，但你常需要数字或布尔值
dotenv 不做类型转换，APP_PORT=3000 读出来是字符串 "3000"，直接传给 server.listen() 会报错 ERR_INVALID_ARG_TYPE；DEBUG=true 也不会自动变成 true。
别在每个使用处手动 parseInt() 或 === 'true'，统一收口处理：
- 封装一个
env模块，导出带类型的访问器：export const PORT = Number(process.env.APP_PORT) || 3000 - 对布尔值用
['true', '1', 'yes'].includes(process.env.DEBUG?.toLowerCase()) - 关键字段（如数据库密码）加非空校验：
if (!process.env.DB_PASSWORD) throw new Error('DB_PASSWORD is required')
本地调试时 VS Code 的 launch.json 怎么配才不冲突
很多人同时用 dotenv.config() 和 VS Code 的 envFile 字段，结果变量被重复加载两次，或者 envFile 优先级更高导致 .env 被忽略。
真实可行的方案只有一个：
- VS Code 的
launch.json中只配"envFile": "${workspaceFolder}/.env"，删掉所有require('dotenv').config() - 因为 VS Code 的
envFile是在 Node 进程启动前注入的，等价于命令行NODE_ENV=dev node index.js，此时process.env已就绪，不需要再用 dotenv 解析 - 这样既避免重复加载，又让调试配置和运行配置完全一致，不会出现“VS Code 里能跑，终端里报错”的情况
最容易被忽略的一点：dotenv 只负责把文件内容挂到 process.env，但它不管这些变量是否真的被你的代码用了。哪怕 .env 里写了 50 行，只要某一行变量名拼错了（比如 DB_PASWORD），程序不会提醒你——直到连不上数据库才暴露。所以启动时的必做动作是：列出所有必需变量，逐个检查 process.env 是否存在且非空。
