环境变量是配置选择的触发器，程序依其值动态加载配置文件（如.env.dev）、决定覆盖行为（via override=true）并注入运行时参数；敏感信息仅走环境变量，结合硬编码默认值、.env基础配置形成三层优先级体系。
环境变量本身不“加载”配置，而是作为触发器或输入源，配合代码逻辑去读取、合并、优先级处理多套配置。真正的动态加载靠的是程序在启动时根据环境变量的值，决定加载哪个配置文件、是否覆盖已有值、从哪一层取默认值。
用环境变量选配置文件名
这是最常用也最清晰的方式。把环境名（如 dev、prod）存在环境变量里，代码据此拼出对应配置文件路径：
- 设置环境变量：
export APP_ENV=prod（Linux/macOS）或set APP_ENV=prod（Windows） - Python 中读取并加载：
env = os.getenv("APP_ENV", "dev")→load_dotenv(f".env.{env}") - 推荐搭配一个基础配置文件
.env，先加载它再加载.env.prod，后者只覆盖同名变量，保留未定义项
用环境变量控制加载顺序和覆盖行为
python-dotenv 的 override 参数和多文件加载顺序共同决定了最终哪些值生效：
-
load_dotenv(".env")：加载通用配置（不覆盖已存在的系统变量） -
load_dotenv(f".env.{env}", override=True)：强制用环境专属配置覆盖前面的值 - 如果系统里已设
DATABASE_URL，默认不会被 .env 文件覆盖；加override=True就会覆盖
用环境变量注入运行时配置项
不依赖文件，直接把关键参数通过环境变量传进来，适合容器化或 CI/CD 场景：
- 例如部署时设置：
DB_HOST=db-prod.internal PORT=443 DEBUG=false - 代码中统一读取：
os.environ.get("DB_HOST", "localhost")、bool(os.environ.get("DEBUG")) - 敏感信息（如密钥）只走环境变量，不写进任何 .env 文件，避免误提交
组合使用更稳健
真实项目通常混合多种方式，形成分层配置体系：
- 最低层：代码内硬编码默认值（仅限无安全风险的兜底项，如重试次数）
- 中间层：.env 文件提供团队共享的基础配置
- 上层：环境变量覆盖关键项（如数据库地址、API 密钥），且优先级最高
- 启动脚本或 Dockerfile 中统一设置
APP_ENV和敏感变量，保证一致性
