Python 3.9的字典合并运算符和pipe符号有何新用途？

本文共计814个文字，预计阅读时间需要4分钟。

Python 3.9 引入的运算符并非为了支持并行，而是为了解决字典合并场景中长期的表述能力和语义模糊问题——它明确表示右覆盖左的不可变追加，不是数学集合操作，也不是深度合并。

为什么 | 比 {**d1, **d2} 更值得用

两者都返回新字典、不修改原对象，但关键差异在可读性、链式能力和错误提示上：

• | 是原生运算符，{**d1, **d2} 是语法糖，后者在键名含非字符串时会静默失败（如 {**{1: 'a'}, **{'b': 2}} 报 TypeError），而 | 对非字符串键完全兼容
• 链式写法更自然：base | overrides | env_vars 比 {**base, **overrides, **env_vars} 少嵌套、易定位错误位置
• 当右操作数不是 dict（比如 OrderedDict 或自定义映射），| 的报错信息明确指出 “right operand must be a mapping”，而 ** 解包可能抛出更晦涩的 TypeError: 'X' object is not iterable

| 和 update() 到底该选哪个

核心区别就一条：是否需要保留原字典不变。

• 用 |：函数参数默认值拼接、配置分层叠加（defaults | user_config | cli_args）、构建一次性的请求 payload
• 用 update() 或 |=：循环内反复累积数据、缓存字典复用、内存敏感场景（避免频繁创建新 dict 对象）
• 注意：d1 |= d2 等价于 d1.update(d2)，但 |= 不支持右操作数为任意映射类型（仅接受 dict 或实现了 items() 的类 dict 对象），而 update() 兼容性更广

哪些坑最容易踩

看似简单，实际高频翻车点集中在类型、版本和嵌套逻辑上：

立即学习“Python免费学习笔记（深入）”；

• None | {} 直接报 TypeError: unsupported operand type(s) —— 必须先判空：(params or {}) | defaults
• list、set、str 不能直接参与 | 运算，哪怕内容看起来像字典（如 JSON 字符串），必须显式 json.loads() 或 dict() 转换
• 嵌套字典被整层替换：{'x': {'a': 1}} | {'x': {'b': 2}} 结果是 {'x': {'b': 2}}，不是 {'x': {'a': 1, 'b': 2}}；需要深度合并请用 deepmerge 或手动递归
• Python 3.8 及以下版本写 d1 | d2 会触发 SyntaxError: invalid syntax，CI/CD 中容易漏测；若需兼容旧版本，只能退回 {**d1, **d2} 或封装工具函数

真正难处理的从来不是怎么写，而是什么时候不该写——比如在热路径里反复用 | 合并大字典，或误以为它能自动 flatten 嵌套结构。这些地方一旦出问题，调试成本远高于多敲几行 update()。