python项目应通过环境变量驱动配置加载，采用base+env分层结构，敏感信息外部化，配合pydantic校验启动检查，确保各环境可预期、可复现、可审计。
Python项目要支持开发、测试、生产等不同环境，核心是把配置和代码分离，避免硬编码，同时保证安全性和可维护性。关键不是“写多少配置”，而是“怎么组织、怎么加载、怎么隔离”。
用环境变量驱动配置加载
不推荐在代码里写 if env == 'prod': ... 这类逻辑。应统一通过 os.environ.get('ENVIRONMENT') 或 os.getenv('ENVIRONMENT', 'dev') 获取当前环境标识，再据此加载对应配置模块或文件。
- 启动时明确指定：如
ENVIRONMENT=prod python app.py - 部署时由容器或运维工具注入（Docker 的
--env、K8s 的envFrom） - 本地开发可用
.env文件配合python-dotenv加载，但该文件绝不能提交到 Git
分层配置结构：基础 + 环境覆盖
建议采用三级结构：base.py（通用常量、默认开关、路径模板）→ dev.py / test.py / prod.py（仅覆盖差异项，如数据库地址、日志级别、调试开关）→ 运行时动态合并。
-
base.py不依赖任何环境变量，只定义骨架 - 各环境配置文件只写 真正不同 的字段，例如
prod.py中DEBUG = False、LOG_LEVEL = 'WARNING' - 用
from base import *+from prod import *方式组合（注意导入顺序），或用pydantic-settings等库做自动合并
敏感信息必须外部化，禁止进代码库
数据库密码、API密钥、JWT密钥等，一律不写在 Python 配置文件中。应通过环境变量或密钥管理服务注入。
立即学习“Python免费学习笔记（深入）”；
- 配置文件中只留占位符，如
DB_PASSWORD = os.getenv('DB_PASSWORD') - CI/CD 流水线中使用 secret 注入，本地开发用
.env（加到.gitignore） - 生产环境优先对接 Vault、AWS Secrets Manager 等，运行时拉取，不落盘
配置验证与启动检查
应用启动前校验必要配置是否存在、格式是否合法，比运行时报错更友好。
- 用
pydantic.BaseSettings或pydantic-settings定义配置模型，自带类型校验和缺失字段提示 - 对必填项（如
DATABASE_URL）设...（Ellipsis）表示不可为空 - 启动时捕获
ValidationError，打印清晰错误（如 “缺少 ENVIRONMENT 环境变量，请设置后重试”）
配置管理不是越复杂越好，而是让每个环境的行为可预期、可复现、可审计。从环境变量切入，用分层结构组织，靠外部化守住安全边界，再加一层验证兜底——这套组合能覆盖绝大多数 Python 服务场景。
