不能无脑替代。字典合并运算符 | 返回新字典且不修改原字典，而 update() 就地修改并返回 None；| 仅浅合并，嵌套字典会被整体替换而非递归合并；链式 | 虽支持多字典合并，但需注意优先级和类型安全。
字典合并运算符 | 能直接替代 update() 吗？
不能无脑替代。它返回新字典，不修改原字典；而 update() 是就地修改、返回 None。配置合并场景下，如果你依赖原字典被改写（比如后续还要复用该变量），用 | 会出错。
base_cfg = {"host": "localhost", "port": 8000}dev_cfg = {"port": 8080, "debug": True}-
merged = base_cfg | dev_cfg→ 新字典，base_cfg不变 -
base_cfg.update(dev_cfg)→base_cfg被改写，返回None
嵌套字典用 | 会浅合并，不是递归合并
这是最常踩的坑：配置里有嵌套结构（比如 {"database": {"url": "...", "pool_size": 10}}），| 只替换整个 "database" 键，不会合并内部字段。
a = {"db": {"host": "a", "port": 5432}}b = {"db": {"port": 5433, "ssl": True}}-
a | b→{"db": {"port": 5433, "ssl": True}}（"host"丢了） - 真要递归合并，得自己写或用第三方库（如
deepmerge），|不解决这事
多个配置字典一次性合并怎么写才清晰？
Python 3.9+ 支持链式 |，但顺序很重要：右边字典的键会覆盖左边同名键。适合“默认值 ← 环境配置 ← 临时覆盖”这种优先级流。
-
default | staging | overrides是常见模式 - 注意：
(default | staging) | overrides和default | (staging | overrides)结果一样（左结合），但语义上建议按优先级从低到高排列 - 避免写成
default | staging | prod | local这种长链——可读性差，调试时难定位哪一层覆盖了哪个键 - 推荐拆成变量：
cfg = default | env_cfg | cli_args，每个变量含义明确
| 在配置加载流程中如何避免意外覆盖？
配置来源多样（文件、环境变量、命令行），用 | 前得确保数据类型干净。常见问题：环境变量读出来是字符串，但配置期望布尔或整数。
立即学习“Python免费学习笔记（深入）”；
-
os.environ.get("DEBUG")返回"True"（字符串），不是True（布尔） - 直接
env_dict | config_dict可能导致类型错乱，运行时才暴露 - 建议先做类型转换再合并，例如：
{"debug": parse_bool(os.getenv("DEBUG"))} - 如果某层配置缺失关键键（比如
"timeout"），|不会报错，而是静默继承左边值——这有时是预期行为，有时是隐患，得靠测试覆盖
真正麻烦的是混合数据源 + 类型不一致 + 浅合并需求，这时候 | 看似简洁，实则掩盖了配置逻辑的复杂性。别为了语法糖跳过校验和转换步骤。
