Python 字典合并与更新：从基础到深度的实践指南与性能考量

76次阅读

共计 3487 个字符，预计需要花费 9 分钟才能阅读完成。

上周帮同事调试一个配置文件解析器时，我发现不少人还在用简单的 dict.update() 处理多层字典合并，结果把数据都覆盖了。其实，Python 在字典操作上有很多巧妙的方法，今天咱们就聊聊如何高效且优雅地合并更新字典，特别是处理嵌套结构时，避免踩坑。

一、基础姿势：浅层合并的 `update()` 与 `|` 运算符

字典合并在日常开发中非常常见，比如合并默认配置和用户自定义配置，或者聚合不同来源的 API 数据。最基础的合并方式主要有两种：dict.update() 方法和 Python 3.9 引入的 | 运算符。

dict.update() 方法
这是最常用的方法之一。它会将一个字典的内容合并到另一个字典中。如果键冲突，右侧字典的值会覆盖左侧字典的值。

# 场景：合并用户基础信息
user_profile = {'id': 101, 'name': 'Alice', 'email': '[email protected]'}
update_info = {'name': 'Alicia', 'phone': '13812345678'}

# 合并前最好先复制一份，避免修改原始字典，这是个好习惯！merged_profile = user_profile.copy()
merged_profile.update(update_info)
print(f"update() 合并结果: {merged_profile}")
# 结果: {'id': 101, 'name': 'Alicia', 'email': '[email protected]', 'phone': '13812345678'}

| 运算符（Python 3.9+）
Python 3.9 引入了新的字典合并运算符 |，让字典合并更加简洁明了。它的行为与 update() 类似，也是“右侧覆盖左侧”。
```
dict_a = {'a': 1, 'b': 2}
dict_b = {'c': 3, 'b': 4} # 'b' 会被覆盖

merged_dict_pipe = dict_a | dict_b
print(f"| 运算符合并结果: {merged_dict_pipe}")
# 结果: {'a': 1, 'b': 4, 'c': 3}
```
小提醒： 无论是 update() 还是 | 运算符，它们都执行的是“浅层合并”。这意味着如果字典中包含嵌套字典，它们只会替换整个嵌套字典，而不会递归地合并内部的键值对。这正是很多新手容易踩坑的地方。

理解了浅层合并后，咱们很快会遇到一个实际问题：如何合并包含嵌套字典的数据？比如一个复杂的配置项，我们希望在不丢失原有子配置的情况下，仅更新其中一部分。这时，浅合并就力不从心了。

要实现深度合并，我们通常需要编写一个递归函数。

自定义递归深度合并函数
这个函数会遍历待合并字典的所有键。如果某个键在两个字典中都存在，并且它们的值都是字典类型，那么就递归调用自身进行合并；否则，右侧字典的值直接覆盖左侧字典的值。

def deep_merge_dicts(dict_a, dict_b):
    """
    深度合并两个字典。对于嵌套的字典，会递归合并；对于其他类型，dict_b 中的值会覆盖 dict_a 中的值。"""
    merged = dict_a.copy() # 这里做 copy() 是避免修改原始 dict_a，我之前爬取配置时，# 忘记了这一步，导致默认配置被意外修改，排查了好久！# 所以，务必先复制一份！for key, value in dict_b.items():
        if key in merged and isinstance(merged[key], dict) and isinstance(value, dict):
            merged[key] = deep_merge_dicts(merged[key], value) # 递归合并子字典
        else:
            merged[key] = value # 非字典或冲突键直接覆盖
    return merged

# 场景：合并默认配置与用户自定义配置
default_config = {'database': {'host': 'localhost', 'port': 5432, 'user': 'admin'},
    'logging': {'level': 'INFO', 'file': 'app.log'},
    'server': {'timeout': 30}
}

user_config = {'database': {'port': 3306}, # 只修改端口
    'logging': {'level': 'DEBUG'}, # 只修改日志级别
    'new_feature': {'enabled': True} # 添加新配置
}

final_config = deep_merge_dicts(default_config, user_config)
print(f"深度合并结果: {final_config}")
# 预期结果:
# {#     'database': {'host': 'localhost', 'port': 3306, 'user': 'admin'},
#     'logging': {'level': 'DEBUG', 'file': 'app.log'},
#     'server': {'timeout': 30},
#     'new_feature': {'enabled': True}
# }

小提醒： 这个自定义的 deep_merge_dicts 函数可以满足大部分深度合并的需求。但它默认对列表等非字典的可迭代对象采取的是“覆盖”策略，而不是“合并”或“追加”。如果你的场景需要合并列表，例如将两个列表的元素合并成一个新列表，那么需要根据具体业务逻辑进一步扩展这个函数。

利用第三方库简化操作（可选）
如果你的项目对字典合并有更复杂、更健壮的需求，比如处理列表合并策略、多种冲突解决机制，那么可以考虑使用成熟的第三方库，例如 deepmerge。它们通常提供了更多的配置选项，减少了自己编写和维护复杂合并逻辑的工作量。

# # 安装: pip install deepmerge
# from deepmerge import always_merger
#
# final_config_lib = always_merger.merge(default_config, user_config)
# print(f"使用 deepmerge 库结果: {final_config_lib}")
# # 小提醒：引入第三方库会增加项目依赖，但对于复杂的合并场景，它可以极大地提升开发效率和代码健壮性。

理解了不同合并方式后，下一个关键点就是何时选择哪种方式，尤其是考虑到性能。

dict.update() 和 | 运算符： 对于非嵌套字典或只需要浅层合并的场景，它们是最高效的选择。因为它们在 Python 的 C 语言底层实现，执行速度非常快。处理百万级别的扁平字典合并，它们也能轻松胜任。
自定义 deep_merge_dicts： 涉及 Python 层的循环和递归调用，其性能开销会比原生方法大。对于几十、几百个键的嵌套字典合并，这点开销基本可以忽略不计。但如果面对数万、数十万个深度嵌套的字典对象，每一次合并的累积开销就会变得显著。

经验总结： 我试过几种合并方法，对于非嵌套字典或浅层合并，Python 自带的 update() 或 | 运算符效率最高，因为它在 C 层面实现了。但对于深度嵌套字典的合并，咱们自己实现的递归函数，在处理几十上百个键的字典时也足够用，没必要过度优化。如果确实遇到处理数万、数十万条记录，且每条记录都是深度嵌套的字典，那可能需要考虑使用 Cython 优化或者重新设计数据结构了。

误区 1: 认为 dict.update() 是深层合并。
我刚开始学 Python 时，总以为 update() 会把所有嵌套字典都智能合并，直到有一次更新配置文件时，发现子字典整个被替换掉了，花了半天时间才搞明白是浅合并的问题。这是新手最常犯的错误之一。
误区 2: 直接在循环中修改原始字典而没有 copy()。
尤其是在进行迭代和修改时，忘记对原始字典进行 copy() 操作，会导致意想不到的副作用。我就曾因为这个坑，在一个多线程任务里，一个线程改了共享的默认配置，影响了其他线程的计算结果，排查了好久。
误区 3: 忽视第三方库的便利性。
很多人觉得“能自己写就不依赖库”，但对于像深度合并这样有明确需求且有成熟解决方案的场景，用 deepmerge 这样的库能省不少时间和精力，而且通常考虑得更周全，避免了自己造轮子可能带来的各种潜在问题。