Python的字典（dict）有个隐藏接口叫__missing__，用来给缺失的键定制返回值。但2024年Fluent Python第二版披露了一组反直觉行为：你精心设计的默认逻辑，有3个入口根本不走这条路。
更麻烦的是，这3个入口的行为还取决于你继承的是dict还是UserDict。同一段代码换了个父类，表现完全不同——这种不一致在标准库里潜伏了二十多年。
当你写key in my_dict时，Python调用的是__contains__方法。这个方法有个设计决策：它从不询问__missing__。
假设你写了一个能自动生成默认值的字典子类，__missing__被触发时会返回一个计算值。但当你用in检查键是否存在，它会直接返回False——哪怕这个键交给__missing__处理完全没问题。
Fluent Python作者Luciano Ramalho在书中举了个例子：一个能根据键的数学规律自动生成值的映射类。d[7]能算出结果，但7 in d却告诉你「不存在」。这对用户来说几乎是认知攻击。
你可以选择覆盖__contains__来修复，代价是语义扭曲。如果你的子类理论上能为任何键提供值，你可以让它永远返回True。但代价也很直观：一个空字典{}，"x" in m也是True——这看起来像是Bug。
dict.get(key, default)是开发者最常用的防御性编程工具之一。但Ramalho指出：这个方法在dict子类里完全绕过__getitem__，直接在C层实现。
这意味着什么？你的__missing__被彻底跳过。用户调用.get()时期望拿到你定制的默认值，实际拿到的却是传入的fallback参数——或者None。
有人试图用「聪明」的方式修复：
def get(self, key, default=None): try: return self[key] # 触发__missing__ except KeyError: return default
这段代码有个致命陷阱。self[key]不会抛出KeyError——它调用__missing__去了。于是except块成了死代码，default参数被彻底无视。更隐蔽的副作用是：键被写进了字典。用户只是想查询，结果数据被污染了。
这里有个分裂的现实。如果你继承的是UserDict，.get()内部会走__getitem__，__missing__正常触发。但换到dict子类，同样的代码逻辑完全不同。collections模块里的这两个类，在继承体系上造成了行为断层。
Python文档其实说得很清楚：__missing__只服务于d[key]这一种语法。连collections.defaultdict都遵守这个契约——它的default_factory只在方括号访问时触发，.get()和in同样免疫。
Ramalho的建议很直接：接受这种分裂，不要试图统一。__missing__和.get()的设计目标本就不同。前者是「这个键值得被记住」，后者是「我只是看看，别动数据」。强行缝合会让两者都失效。
但这给API设计者出了道难题。你的字典子类用户不会记得这些细节。他们会在文档里看到「自动提供默认值」，然后理所当然地认为.get()和in也该如此。这种预期落差在生产环境里很难调试——代码不报错，只是行为 silently wrong。
继承选择的蝴蝶效应
Python标准库在这里埋了个历史包袱。dict是内置类型，核心方法用C实现以追求速度。UserDict是纯Python的包装器，方法调用走Python层，所以能尊重__getitem__的覆盖逻辑。
这种差异在1990年代合理——当时dict的性能至关重要。但2024年的开发者继承dict时，很少意识到自己在放弃对.get()行为的控制。Ramalho在Fluent Python第二版里把这个案例放在「对象引用、可变性与回收」章节，暗示这是Python对象模型的深层特性，而非简单的「使用技巧」。
一个具体的决策树：如果你需要__missing__覆盖所有访问方式，继承UserDict；如果你能接受.get()和in走独立逻辑，且需要极致性能，继承dict。没有银弹，只有权衡。
社区里有过讨论是否该让dict.get也尊重__missing__，但向后兼容性锁死了这个可能。任何改变都会让现有代码的行为发生漂移——而字典是Python最基础的构件之一。
最后留个细节。Ramalho在书中提到，__contains__的覆盖决策取决于你的抽象是否「全函数」——即是否每个键都有对应值。如果是，return True合理；如果不是，保持默认行为对用户更诚实。这个判断没有自动化测试能帮上忙，只能靠设计者对使用场景的理解。
你的项目里有自定义字典类吗？检查一下.get()和in的行为，它们真的在做你预期的事吗？
热门跟贴