字典合并运算符 | 返回新字典、不修改原字典，右操作数同名键覆盖左操作数；仅左操作数须为 dict，右操作数可为任意实现 keys() 和 __getitem__() 的映射类型；不支持嵌套合并，仅为浅合并。
字典合并运算符 | 的基本用法
Python 3.9 引入的 | 是真正的“合并”而非“更新”：它返回一个新字典，不修改原字典，且右操作数的键值对会覆盖左操作数中同名键的值。
常见错误是把它当成 dict.update() 用——后者就地修改、返回 None，而 | 必须赋值给变量才有效果。
-
d1 = {"a": 1, "b": 2}；d2 = {"b": 3, "c": 4}→d1 | d2得到{"a": 1, "b": 3, "c": 4} - 左操作数必须是
dict类型，list | dict或str | dict直接报TypeError: unsupported operand type(s) - 右操作数可以是任意映射类型（如
collections.OrderedDict），但必须实现keys()和__getitem__()
与 ** 解包和 merge() 的区别
很多人习惯用 {**d1, **d2} 合并字典，但它在 Python 3.9+ 中已不是最优选：| 更清晰、更高效（避免临时构造多个 dict）、且语义明确（就是“合并”，不是“解包再构造”）。
collections.ChainMap 不是替代方案——它只是逻辑上叠加，不生成新字典；dict.merge() 并不存在，那是误记（Java 或某些第三方库的命名）。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
-
|支持链式使用：d1 | d2 | d3，而{**d1, **d2, **d3}虽然也行，但可读性差、且中间解包可能触发重复键警告（尽管不报错） -
|=是就地更新版本，等价于d1.update(d2)，但要求左操作数必须是dict实例（不能是dict子类或其它 Mapping） - 性能上，
|比{**d1, **d2}快约 10–15%，尤其在小字典场景下差异明显（CPython 3.9+ 内部做了专门优化）
容易踩的坑：不可变对象、嵌套字典与类型检查
| 只做一层浅合并，完全不递归。如果字典里嵌套了字典，不会自动合并内层，而是直接用右边的整个嵌套结构覆盖左边对应键。
静态类型检查工具（如 mypy）默认不识别 | 的返回类型为 dict，需升级到 mypy ≥ 0.910 并启用 --python-version 3.9 才能正确推导。
- 错误预期：
{"x": {"y": 1}} | {"x": {"z": 2}}→ 得到的是{"x": {"z": 2}}，不是{"x": {"y": 1, "z": 2}} -
frozenset、tuple等不可变类型不能作为左操作数：frozenset() | {"a": 1}报错，因为左操作数必须支持__or__且由dict实现 - 若用
typing.Dict注解变量，mypy 可能报Unsupported left operand type for |；改用dict（内置类型）或升级 typing 信息可缓解
兼容性与降级方案
如果你的代码需要同时支持 Python |。没有语法糖能完全替代它，但可封装成函数模拟行为。
注意：不要用 copy.deepcopy(d1); d1.update(d2) 来模拟 |——它深拷贝开销大，且破坏了 | 的不可变语义（原字典不该被 touch）。
- 安全降级写法：
def merge_dicts(a, b): return {**a, **b}（适用于所有 Python 3.5+，但丢失类型提示精度） - 想保留类型提示？可用
typing.overload配合sys.version_info分支，不过实际项目中往往直接要求最低 Python 版本更省事 - CI 流程中记得测试
|行为：比如验证len(d1 | d2) == len(set(d1.keys()) | set(d2.keys()))是否成立，能快速捕获误用
真正要注意的是嵌套合并这个盲区——它看起来像该递归，但语言层面故意没这么做。需要深层合并时，老实用 deepcopy + 递归函数，别试图魔改 |。
