ChainMap 通过构造时映射顺序实现高优先级覆盖：将高优先级配置（如命令行参数）置于 ChainMap 参数前列，查找时命中即返回，后续同名键被忽略；它仅做一层键查找，不递归合并嵌套结构。
ChainMap 怎么让高优先级配置覆盖低优先级配置
ChainMap 本身不合并字典，而是按顺序查找键——从第一个映射开始，找到就返回，后续映射里的同名键被自动忽略。这意味着只要把高优先级配置（如命令行参数、环境变量）放在 ChainMap 构造参数的前面，低优先级（如默认配置文件）放后面，就能天然实现“覆盖”语义。
常见错误是误以为 ChainMap 会递归合并嵌套结构，其实它只做一层键查找；遇到嵌套 dict（比如 {"db": {"host": "localhost"}}），它不会深入合并子字段，只是把整个 "db" 键的值原样返回。
- 构造时顺序即优先级：
ChainMap(cli_args, env_vars, config_file, defaults) - 修改操作（
map[key] = value）默认写入第一个映射，不影响后续映射 - 想修改底层映射需显式访问：
map.maps[2]["timeout"] = 30
如何安全地更新多层配置而不污染原始数据
ChainMap 的 maps 属性是公开的 list，直接修改其中某个 dict 会影响原始数据源。如果原始配置来自 json.load() 或 os.environ，意外修改可能导致副作用。
推荐做法是用 new_child() 创建隔离副本，或对可变源做浅拷贝。例如命令行参数通常可变，应先 copy.deepcopy() 再传入；而 os.environ 是只读视图，可直接用，但别对它赋值。
- 用
ChainMap().new_child(override_dict)动态插入新层，不影响原有链 - 避免直接改
map.maps[0]，除非你明确知道那个 dict 是临时的 - 对 JSON 配置文件内容，建议用
copy.copy()（非嵌套）或copy.deepcopy()（含嵌套 dict/list）
ChainMap 查找失败时怎么 fallback 到默认值
ChainMap 本身不提供类似 dict.get(key, default) 的接口
map.get(key) 行为等价于 map[key] —— 找不到就抛 KeyError。必须手动处理缺失逻辑。
最简方式是用 next((m[key] for m in map.maps if key in m), default_value)，但注意这会触发多次 in 检查；更高效的是封装成工具函数，或改用 collections.ChainMap(map1, map2).get(key, default)？等等——这个 get 方法其实**不存在**，ChainMap 没有实现 get 方法，调用它会回退到 Mapping.get 默认行为（即报 AttributeError）。
- 正确 fallback 写法：
map[key] if key in map else default_value - 或者预构建一个带默认层的 ChainMap：
ChainMap(user_cfg, defaults)，再统一用key in map判断 - 别依赖
map.get(key, default)，它会报错
为什么 ChainMap 比嵌套 dict.update() 更适合配置管理
因为 update 会破坏原始数据、无法回溯、难以调试哪一层改了什么。ChainMap 把各层配置保持独立，运行时可随时 inspect map.maps 查看每一层内容，也能用 map.parents 快速去掉最高优先级层（比如测试时临时屏蔽 CLI 参数）。
性能上，ChainMap 查找是 O(n)（n 是映射层数），但每层内部仍是哈希查找 O(1)；而深度 merge 配置可能涉及大量 deepcopy 和递归遍历，在配置量大或嵌套深时更慢且内存开销高。
- 调试友好：
print(map.maps)直接看到所有配置源及其顺序 - 动态增删层：
map = map.new_child(temp_override)/map = map.parents - 不支持嵌套合并，所以别指望它处理
{"logging": {"level": "INFO"}}和{"logging": {"format": "%(msg)s"}}的自动合并——那得自己写逻辑或换用deepmerge
