Python项目配置管理核心是代码与配置分离，通过环境变量（如ENVIRONMENT）标识环境并动态加载base/dev/test/prod三层配置，敏感信息外置且运行时注入，统一在config.py中验证加载。
Python项目配置管理的核心是把代码和配置分离，避免硬编码、重复维护和环境误用。多环境（开发、测试、生产）下，关键不是“怎么存配置”，而是“怎么让配置在正确环境加载正确值”。
环境标识要明确且可传递
靠代码里写 if env == 'prod' 不可靠，容易漏改或误判。推荐用环境变量 ENVIRONMENT 或 FLASK_ENV（如用 Flask）统一控制，启动时由外部注入：
- 开发：启动命令加
ENVIRONMENT=dev python app.py - Docker：在
docker-compose.yml的environment字段设值 - K8s：通过
env:或 ConfigMap 注入
程序启动时读取该变量，决定加载哪套配置，不依赖当前机器名、路径或 Git 分支。
配置分层：基础 + 环境覆盖 + 运行时注入
建议三层结构，自上而下优先级递增：
立即学习“Python免费学习笔记（深入）”；
- base.py：通用配置，如日志格式、默认超时、基础路径
- dev.py / test.py / prod.py：只写差异项，如数据库 URL、调试开关、密钥来源（本地文件 or AWS Secrets Manager）
-
运行时环境变量：最高优先级，用于临时覆盖（如调试时改 API 地址），用
os.getenv()直接读取，不写进配置文件
这样既保持配置可读性，又支持灵活覆盖，也方便 CI/CD 流水线动态注入敏感信息。
敏感信息绝不进代码库
数据库密码、API 密钥、JWT 秘钥等必须从外部加载：
- 本地开发可用
.env文件（配合python-dotenv），但确保.gitignore忽略它 - 生产环境禁用
.env，全部走系统环境变量或云平台密钥服务（如 AWS Secrets Manager、Azure Key Vault） - 配置类中用
os.getenv('DB_PASSWORD', default=None)显式声明缺失时报错，不给空字符串兜底
验证与加载逻辑要集中、可测
不要在每个模块里零散读配置。建一个 config.py，统一完成：
- 根据
ENVIRONMENT动态导入对应配置模块 - 对必填字段做存在性检查（如
DB_URL为空则抛异常） - 提供
get_config()入口，返回实例化的配置对象（非字典），便于类型提示和 IDE 补全 - 单元测试里可 mock 环境变量，验证不同环境是否加载了预期值
这样配置加载行为清晰、可追溯，上线前也能快速断言关键配置已就位。
