应统一配置管理：用 pydantic-settings 作为唯一入口，禁用直接调用 os.getenv 或 configparser；pyproject.toml 仅存工具链配置；按环境变量加载对应配置文件；避免热更新，优先重启进程。
配置分散在多个地方，os.getenv 和 configparser 混用导致行为不一致
Python 项目里配置一多，很容易变成环境变量、INI 文件、JSON、硬编码常量四处开花。最典型的问题是：同一个配置项，os.getenv('DEBUG') 返回 '1'，但 configparser 读出来却是 'true' 或 True（如果手动转了），结果日志开关没生效，还以为代码逻辑错了。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 统一入口：只用一个配置加载器，比如
pydantic-settings，它能自动把DEBUG=1转成bool，也支持从.env、环境变量、命令行参数按优先级合并 - 禁止在业务代码里直接调
os.getenv或configparser.read；所有配置必须经由一个Settings实例提供 - 类型声明即约束：在
Settings类里写debug: bool = False，比写注释“这个值应为布尔”管用十倍
pyproject.toml 里塞太多构建/测试/格式化配置，反而让运行时配置更难找
pyproject.toml 确实适合放 black、mypy、pytest 配置，但它不是运行时配置的归宿。常见错误是把数据库 URL、API 密钥、超时时间全堆进去，然后用 tomllib 手动读——既没类型检查，又绕过环境变量覆盖机制，CI/CD 里改个配置还得改提交。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
pyproject.toml只管工具链，运行时配置交给独立文件（如config.yaml）或环境变量 - 如果非要用 TOML 做运行时配置，务必配
pydantic-settings的YamlConfigSettingsSource或自定义TomlConfigSettingsSource，别手写解析逻辑 - 注意
pyproject.toml默认会被pip安装进包里，敏感配置塞进去等于公开泄露
不同环境（dev/staging/prod）靠 if 分支切换配置，导致分支爆炸和漏测
写一堆 if env == 'prod': DB_URL = ... else: DB_URL = ...，短期看着省事，长期就是灾难：新环境加个判断，忘了改测试；staging 配置抄 prod 少了个 timeout，压测就超时；更糟的是，这种逻辑藏在模块深处，pytest 启动时根本不知道自己跑在哪种配置下。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用环境变量驱动配置加载，而不是用代码分支：启动时设
ENVIRONMENT=staging，配置类自动加载staging.yaml或合并对应字段 - 配置类本身要支持「继承」：base 配置定义通用字段，dev/staging/prod 各自只覆盖差异项，避免重复
- CI 流水线里强制跑一次
python -c "from myapp.config import settings; print(settings.model_dump())"，确认最终配置符合预期
配置热更新被当成银弹，实际引发状态不一致
有人觉得加个 watchdog 监听 config.yaml 变更，然后 reload settings 对象，就能实现配置热更新。问题在于：HTTP 连接池、数据库连接、缓存 client 都不会自动跟着变；旧配置可能还在某个线程里执行，新配置已生效，结果一半请求走新超时、一半走旧超时。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 绝大多数 Python Web 服务（FastAPI/Flask）不推荐热更新配置；重启进程更安全、更可控
- 真需要动态行为（比如降级开关），用专门的机制：Redis 标志位 + 定期轮询，或
threading.local()缓存当前值 + 全局锁更新 - 如果坚持 reload，必须确保所有依赖配置的组件都支持重初始化，并在更新前后做原子性校验（比如对比新旧
DB_URL是否指向同一实例）
配置治理最难的不是语法或工具，而是让所有人接受「配置即代码」——要版本控制、要类型约束、要测试覆盖、要变更审批。一旦允许某处临时硬编码、某次跳过校验、某人绕过配置中心，复杂度就立刻反弹。
