配置合并遵循“后写入者胜出”原则，优先级由加载顺序决定：基础配置→环境配置→本地 / 秘密配置；需区分简单赋值覆盖与深度合并，并通过日志溯源、统一入口和环境变量检查确保可追溯性。
Python 项目中 配置文件 合并的核心原则是：后加载的配置覆盖先加载的配置，即“后写入者胜出”。优先级由加载顺序决定，而非文件位置或名称。
配置加载顺序决定优先级
配置值最终生效取决于它们被读取和写入配置对象的先后次序。例如使用 python-decouple、dynaconf 或手写 configparser 合并逻辑时，通常按如下典型顺序加载：
- 基础配置（如 default.toml）最先加载，提供默认值
- 环境配置（如 development.toml）其次加载，覆盖部分默认项
- 本地 / 秘密配置（如 local.yml 或 .env）最后加载，用于覆盖敏感或机器专属设置
常见合并方式与覆盖行为
不同 工具 对“合并”的定义略有差异，需注意嵌套结构是否深度合并：
- 简单赋值式（如 os.environ.update + dict.update）：仅顶层键覆盖，子字典整体替换。例如 {“db”: {“host”: “a”}} 被 {“db”: {“port”: 5432}} 覆盖后，host 丢失
- 深度合并（如 dynaconf merge 或 mergedeep）：递归合并嵌套字典，保留未被明确覆盖的子字段
- 环境变量 优先（如 decouple.AutoConfig）：环境变量始终最高优先级，即使代码中后加载 config 文件，ENV 仍会覆盖它
推荐实践：显式控制 + 可追溯性
避免隐式合并带来的意外覆盖，建议：
立即学习“Python 免费学习笔记（深入）”；
- 在启动日志中打印实际生效的配置来源（例如“DB_HOST ← from .env”）
- 用统一入口函数加载配置，禁止多处零散调用 configparser.read() 或 load_dotenv()
- 对必须强制继承的配置（如日志格式），使用只读封装或运行时校验，而非依赖合并逻辑
调试技巧：快速验证优先级
当不确定某配置为何没生效时：
- 临时在加载各文件后打印 config.dict() 或 dict(config)，观察变化过程
- 检查环境变量是否意外存在（print(os.environ.get(‘DEBUG’))），它们常被忽略但优先级极高
- 确认文件 编码 和语法（尤其 YAML 中缩进、冒号空格），解析失败会导致该文件静默跳过
