Python 3.9+ 的 | 运算符仅支持 dict 或明确实现 __or__ 的映射类型（如 defaultdict），不兼容 None、list、ChainMap 等；| 左结合，右字典覆盖优先，每步新建字典；|= 原地更新更省内存，但要求右操作数为映射类型。
| 运算符能高效合并多个映射，但必须全是 dict 或明确支持 __or__ 的映射类型；它不自动降级处理 None、list、ChainMap 或含不可哈希键的结构——出错就是运行时报 TypeError，不是静默跳过。
哪些类型能直接参与 | 链式合并？
只有左操作数必须是 dict，右操作数可以是任意实现了 __or__ 的映射（如 collections.abc.Mapping 子类），但实际中强烈建议两边都用 dict：
-
dict | dict：完全安全，推荐写法 -
dict | defaultdict：可行，但若defaultdict重写了__or__，行为可能偏离预期 -
dict | ChainMap：会报TypeError: unsupported operand type(s)，因为ChainMap没实现__or__ -
dict | None或dict | []：直接崩溃，None和list不是映射类型
合并多个字典时顺序和结合性怎么影响结果？
| 是左结合的，d1 | d2 | d3 等价于 (d1 | d2) | d3，每步都新建一个字典。这意味着：
- 最右边的字典拥有最高覆盖优先级，它的键值无条件覆盖左边所有同名键
- 中间结果不会复用，比如
d1 | d2生成的临时字典在下一步就被丢弃 - 如果
d2很大而d3很小，仍要先复制d1 | d2全量内容，再合并d3——内存开销是线性的 - 没有“一次性遍历所有字典”的底层优化，不要误以为它比循环
update()更省内存
遇到非 dict 输入时怎么安全 fallback？
真实项目里，用户配置、API 返回或函数参数常为 None、空迭代器、自定义配置类，不能硬套 |。必须提前做类型/存在性检查：
- 用
isinstance(x, dict)判断是否可直接参与|，否则转成dict或跳过 -
user_config or {}比user_config | {}更安全——后者在user_config是None时直接炸 - 需要深合并？别碰
|，改用deepcopy+ 递归，或引入deepmerge库 - 想兼容旧版本 Python？降级用
{**d1, **d2, **d3}，它对非字符串键更敏感，但至少不会语法报错
为什么 d1 |= d2 有时比 d1 | d2 更适合批量合并？
当你要把十几个字典依次合并进一个主字典（比如加载多层配置），| 链式写法会产生大量临时对象，而 |= 是原地更新，只操作一次哈希表：
立即学习“Python免费学习笔记（深入）”；
-
config |= defaults; config |= env_config; config |= cli_args—— 只修改config本身，无中间字典 -
config = defaults | env_config | cli_args—— 创建两个临时字典，再丢弃 -
|=要求右操作数必须是映射类型，但校验比update()更严：传list或set会立刻报TypeError，而不是静默失败 - 注意：
d1 |= d2等价于d1.update(d2)，但语义更统一，且避免了update()返回None导致链式中断的问题
config = base | user | overrides 看似干净，但只要其中任意一个变量是 None 或自定义类（哪怕它有 .items()），就会在运行时崩，而不是在 IDE 或类型检查阶段暴露。别依赖“看起来像字典就一定能合”，该加的 isinstance 和 or {} 一个都不能少。 
