Python 3.9 的 | 运算符实现字典的浅层、右优先键值对覆盖合并，不修改原字典，不支持嵌套结构，返回新字典，要求键可哈希，语义清晰且类型安全。
Python 3.9 的 | 运算符到底合并什么
它不是“深合并”，也不是“递归覆盖”，而是对字典做**浅层、右优先的键值对覆盖合并**。左侧字典的键如果在右侧也存在，右侧的值直接生效；所有键被收集进一个新字典，原字典完全不动。
常见误解是以为 | 能处理嵌套字典或列表值——它不能。比如 {"a": {"x": 1}} | {"a": {"y": 2}} 结果是 {"a": {"y": 2}}，不是 {"a": {"x": 1, "y": 2}}。
-
|返回新字典，不修改任一操作数 - 左操作数必须是
dict，右操作数可以是任意映射（如dict、Mapping子类），但实际中建议都用dict - 键类型需支持哈希，否则运行时报
TypeError: unhashable type
和 update()、{**a, **b} 的关键区别
update() 是就地修改，{**a, **b} 在 Python 3.5+ 可用但语法稍冗、且对非字符串键的映射支持弱（比如含非字符串键的 dict 会报错）；而 | 是纯函数式、类型安全、语义清晰的二元运算。
-
a.update(b)→ 修改a，返回None；a | b→ 返回新dict，a和b都不变 -
{**a, **b}在b含非字符串键时可能失败（如b = {1: "one"}在某些旧解释器或严格模式下报错），a | b没这个问题 - 性能上三者接近，但
|在可读性上胜出：一眼看出“合并”意图，而非靠解包符号猜逻辑
遇到不可哈希键或自定义映射时的 fallback 方案
如果右操作数是自定义类（比如继承 dict 但重写了 __or__），或者你想合并含不可哈希键（如列表）的结构，| 会直接抛 TypeError。这时候不能硬扛，得降级。
立即学习“Python免费学习笔记（深入）”；
- 先用
isinstance(b, dict)做类型兜底，再决定是否用| - 需要深合并？别碰
|，改用copy.deepcopy()+ 递归遍历，或引入deepmerge库 - 想兼容旧版本（
真实项目里容易忽略的边界点
很多人写 config = default_config | user_config 就以为万事大吉，但没考虑 user_config 可能为 None 或空迭代器。此时 | 会直接报错，而不是静默跳过。
-
None不是映射，不能参与|，必须提前检查：user_config or {} - 空字典没问题：
a | {}就是a的副本，但{} | a也是等价的 - 如果合并链长（如
a | b | c | d），注意这是左结合：((a | b) | c) | d，每步都新建字典，大量合并时内存开销比循环update略高
真正优雅不在于用了新语法，而在于你清楚它在哪停下——它只负责一层扁平合并，再多的，得你自己接住。
