Python 工程中配置与代码的边界划分

配置应与业务逻辑分离，通过命名空间化键名、环境变量优先、启动校验和不可变加载确保可维护性；Pydantic Settings 需适配嵌套结构，测试时须隔离配置作用域。

配置不该出现在 if 判断里

把配置值直接塞进业务逻辑的条件分支中，等于把可变因素硬编码进流程控制——下次换环境就得改代码、重新测试、再发布。比如写 if env == "prod": use_redis = True，看似简单，实际让 env 同时承担运行环境标识和行为开关双重职责，一旦加个灰度环境或中间态，if 链就失控。

正确做法是：配置只负责提供原始值，逻辑只依赖明确的布尔开关或枚举项：

• USE_CACHE = config.getboolean("cache", "enabled")（而不是推导自 ENV）
• 用 config.get("database", "url") 直接取连接串，别在代码里拼 "mysql://" + host + ":" + port
• 所有配置键名带命名空间，如 Logging.level、api.timeout_seconds，避免裸名 timeout 引发歧义

os.environ 和配置文件谁该优先？

环境变量优先级必须高于文件配置，这是 12-Factor app 的硬性要求，也是 docker/K8s 场景下的事实标准。但很多人只做 os.environ.get("DB_URL") or config.get("db.url")，漏掉了类型转换和缺失兜底。

实操建议：

立即学习“Python免费学习笔记（深入）”；

• 用 os.getenv("LOG_LEVEL", "INFO").upper()，不依赖 configparser 默认值机制
• 敏感配置（如密钥）只允许从环境变量读，配置文件里留空或写 ***REDACTED*** 作提示
• 启动时校验必填项是否存在，缺失则报错退出，别等第一次调用 DB 才抛 KeyError

Pydantic Settings 不是万能胶水

用 BaseSettings 管理配置很常见，但它默认把环境变量名转成大写下划线（DB_URL → db_url），而实际项目常需保留大小写或点号分隔（如 kafka.bootstrap_SERVERS）。强行靠 field(env="KAFKA_BOOTSTRAP_SERVERS") 写一堆映射，反而比手写解析还累。

更稳的路径：

• 用 pydantic-settings（v2+）配合 SettingsConfigDict(env_nested_delimiter=".") 支持点号嵌套
• 对多层级结构（如 features.flag_x.enabled），优先用 jsON/YAML 配置文件，环境变量仅覆盖叶子节点
• 避免在 Settings 模型里写业务逻辑方法，比如 def db_url(self) 做字符串拼接——这又把配置和代码缠在一起了

测试时配置怎么隔离？

单元测试跑着跑着连上了真实 Redis，八成是没切断配置加载链路。最危险的是全局单例（如 settings = Settings() 在模块顶层），导致一个 test case 改了配置，后续全乱。

关键动作：

• 测试前用 monkeypatch.setenv("DB_URL", "sqlite:///test.db") 替换环境变量，而非修改配置对象属性
• 用 tmp_path 写临时配置文件，确保每个 test 用独立路径，避免并发冲突
• 禁止在 conftest.py 里初始化任何配置实例，所有 fixture 显式传参或延迟构建

配置和代码的边界不是靠文档约定，而是靠加载时机、作用域和不可变性来守住。越早把配置解析从 import 阶段剥离，越少遇到“为什么本地跑得通，CI 就挂”的问题。