Python 3.9中的字典合并运算符“|”该如何使用？-Python教程-PHP中文网

字典合并运算符 | 返回新字典、不修改原字典，右操作数同名键覆盖左操作数；仅左操作数须为 dict，右操作数可为任意实现 keys() 和 __getitem__() 的映射类型；不支持嵌套合并，仅为浅合并。

python 3.9中的字典合并运算符“|”该如何使用？

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__()

很多人习惯用 {**d1, **d2} 合并字典，但它在 Python 3.9+ 中已不是最优选：| 更清晰、更高效（避免临时构造多个 dict）、且语义明确（就是“合并”，不是“解包再构造”）。

collections.ChainMap 不是替代方案——它只是逻辑上叠加，不生成新字典；dict.merge() 并不存在，那是误记（Java 或某些第三方库的命名）。

| 支持链式使用：d1 | d2 | d3，而 {**d1, **d2, **d3} 虽然也行，但可读性差、且中间解包可能触发重复键警告（尽管不报错）
|= 是就地更新版本，等价于 d1.update(d2)，但要求左操作数必须是 dict 实例（不能是 dict 子类或其它 Mapping）
性能上，| 比 {**d1, **d2} 快约 10–15%，尤其在小字典场景下差异明显（CPython 3.9+ 内部做了专门优化）

| 只做一层浅合并，完全不递归。如果字典里嵌套了字典，不会自动合并内层，而是直接用右边的整个嵌套结构覆盖左边对应键。

提示词大师-python版

图片提示词生成器？不止如此。马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。输入「新手指南」查看完整功能介绍

下载

静态类型检查工具（如 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 + 递归函数，别试图魔改 |。