ChainMap 初始化时直接传入多个字典，创建按顺序查找的视图而非合并新字典；内部维护 maps 列表，查找从左到右，靠前字典优先级高，修改仅作用于 maps[0]，不改变原始字典。
ChainMap 初始化时直接传入多个字典
ChainMap 不是通过“合并”生成新字典，而是创建一个按顺序查找的视图。最直接的方式是在初始化时把多个 dict 对象作为位置参数传入：ChainMap(dict1, dict2, dict3)。它内部维护一个映射列表（maps），查找时从左到右依次尝试。
常见错误是误以为 ChainMap.update() 或 ** 解包能“合并”它——实际上 ChainMap 没有 update() 方法，也不能用字典解包语法构造。
- 正确写法：
from collections import ChainMap; cm = ChainMap(dict_a, dict_b, dict_c) - 错误写法：
ChainMap({**dict_a, **dict_b})（这是普通字典合并，和 ChainMap 无关） - 注意顺序：靠前的字典具有更高优先级，同名 key 会屏蔽后面字典中的值
修改 ChainMap 的第一层映射（而非“合并后”的结果）
ChainMap 本身不可变，但它的第一个映射（cm.maps[0]）默认是可写的空字典。你可以向它写入或更新，从而影响整个 ChainMap 的行为，这常被误认为是“合并后修改”。
使用场景包括：临时覆盖配置、注入运行时参数。但要注意，这不会改变原始传入的字典，只影响 maps[0] 这一层。
立即学习“Python免费学习笔记（深入）”；
- 添加新键：
cm['new_key'] = 'value'→ 写入cm.maps[0] - 覆盖已有键：
cm['existing'] = 'override'→ 同样作用于maps[0]，屏蔽后续字典中同名 key - 若想禁止写入，可显式传入只读字典：
ChainMap({}, dict_a, dict_b)，再将{}设为cm.maps[0].clear()后只读（需自行封装保护逻辑）
ChainMap 与 dict(**) 合并的本质区别
很多人想用 ChainMap 替代 {**d1, **d2, **d3}，但二者语义完全不同：** 是深拷贝+覆盖合并，生成全新字典；ChainMap 是浅层视图，不复制数据，也不扁平化结构。
性能上，ChainMap 初始化 O(1)，查找最坏 O(n)（n 是字典个数）；而 {**...} 是 O(Σlen(d)) 时间 + 额外内存开销。兼容性方面，ChainMap 在 Python 3.3+ 可用，且支持动态增删映射（cm.new_child() / cm.parents）。
- 要“真正合并”成一个字典：必须手动构建，如
dict(d3, **{**d2, **d1})（注意覆盖顺序） - 要“逻辑上优先查 d1，缺了再查 d2”：用
ChainMap(d1, d2)，零内存复制 - ChainMap 的
maps是公开属性，可随时.append()新字典，但要注意这会影响所有后续查找
嵌套 ChainMap 和 new_child() 的典型误用
new_child() 常被当作“合并子配置”，但它只是在当前 maps 列表头部插入一个新字典（默认为空），不是把当前 ChainMap 和另一个 ChainMap 合并。容易混淆的是：传入参数是字典，不是 ChainMap。
例如：cm.new_child({'host': 'localhost'}) 返回新 ChainMap，其 maps[0] 是这个新字典，maps[1:] 是原 cm.maps。这不是递归合并，也不会展平嵌套的 ChainMap。
- 错误理解：
ChainMap(d1).new_child(ChainMap(d2))→ 实际传入的是ChainMap(d2)对象本身，会被当普通字典（只有keys()方法），导致运行时报错TypeError: unhashable type: 'ChainMap' - 正确做法：若需多层嵌套逻辑，应逐层用字典构造，或用
ChainMap(*all_dicts) - 调试技巧：打印
cm.maps能立刻看清当前查找链，比盲目调用new_child()更可靠
len(cm) 返回所有唯一 key 数量，或遍历得到扁平键值对），就会踩坑——它不提供这些行为，得自己封装或换用其他结构。 
