__missing__ 方法是在 Python 2.5 中引入的，作为一个子类钩子，以支持自动生成模式，早于 collections.defaultdict 实现几个版本。它允许字典子类为缺失键定义自定义行为，而无需从头重写整个 __getitem__ 逻辑。从历史上看，这使得在标准库提供专用容器类型之前，为递归数据结构提供优雅的解决方案。
当 dict.__getitem__ 无法找到请求的键时，它会检查类字典中是否存在 __missing__，并将调用委托给该方法，而不是立即引发 KeyError。潜在的危险在于，当实现尝试使用括号符号 self[key] = value 存储默认值时，这会再次内调用 __getitem__，并递归触发 __missing__。这会导致无限循环，只有当 C 运行时堆栈溢出时才终止，导致解释器崩溃。
解决方案要求完全绕过被重写的 __getitem__，通过使用 dict.__setitem__(self, key, value) 或 super().__setitem__(key, value) 直接将默认值插入基础哈希表。这种技术确保了在方法内进行任何后续访问尝试之前，键已经存在。然后该方法应返回新创建的值，以满足原始查找请求而不产生递归。
class NestedDict(dict): def __missing__(self, key): # 避免 self[key] = value 来防止递归 value = NestedDict() dict.__setitem__(self, key, value) return value # 用法: config['level1']['level2'] = 'data' 运行顺畅
我们的配置管理系统需要支持任意深度嵌套的环境特定重写，开发人员希望在不验证中间键的情况下编写 settings['production']['database']['ssl']['enabled']。标准字典实现会在第一个缺失段上引发 KeyError，迫使防御性编码模式，使业务逻辑变得复杂，以重复的存在性检查来避开这一问题。我们需要一个保持JSON序列化兼容性的数据结构，同时在读取和写入操作中提供隐式的中间节点创建。
第一种方法涉及模式验证，在初始化过程中预填充所有可能路径的空字典实例。这确保了在访问之前内存中存在任何有效路径，完全消除了查找失败，并使读取性能更快。然而，对于仅有十个百分点的路径实际使用的稀疏配置来说，它消耗了过多的内存，并且将代码紧密耦合到一个刚性的模式中，当添加新的配置键时需要重新部署。
随后，我们考虑了如 safe_get(settings, 'production', 'database') 的工具函数，这些函数在缺失段中返回空字典，而不修改原始结构。这些函数在遍历过程中防止了异常，但无法支持像 settings['production']['new_key'] = value 这样的赋值语法，因为它们返回的是临时对象，而不是对嵌套存储的引用。此外，非标准 API 让新团队成员感到困惑，并需要 extensive documentation 来确保在代码库中的一致使用。
最终，我们实现了一个 NestedDict 类，重写 __missing__ 以实例化和使用 dict.__setitem__ 存储新的 NestedDict 实例，以避免递归陷阱。这保留了原生字典接口，与现有 JSON 解析库无缝集成，同时仅对已访问路径进行了懒惰初始化。之所以选择这个方案，是因为它对消费者代码模式没有任何更改，并消除了模式同步的维护负担。
部署后，我们观察到与配置相关的样板代码减少了70%，并且在部分配置更新期间完全消除了生产日志中的 KeyError 崩溃。内存开销保持最佳，因为只有访问过的配置分支才会在内存中出现，结构可以标准 JSON 反序列化，而无需自定义编码器。开发者满意度调查表明，直观的语法大大减少了对不熟悉代码库的工程师的入门时间。
为什么 dict.get() 完全绕过 __missing__，这种不对称如何影响错误处理策略？
dict.get() 方法在 C 级别直接查找基础哈希表，如果缺少键的哈希值，则立即返回默认值，而不调用 Python 级别的 __getitem__ 方法。因此，即使您的子类定义了复杂的 __missing__ 方法来记录警告或计算昂贵的默认值，get() 也会静默地返回 None 或指定的默认值，而不会触发该逻辑。为了保持一致性，您必须显式重写 get()，将其委托给 __getitem__，或者接受 get() 和括号访问对于缺失键有不同的行为，这常常让期望实现一致自动生成的开发人员感到惊讶。
如果 __missing__ 访问字典中的其他键，会如何触发无限递归，什么特定编码模式可以防止这种情况？
如果 __missing__ 实现尝试在处理缺失键请求时通过 self[other_key] 读取无关键，而那个其他键也缺失，Python 会在第一次调用返回之前再次调用 __missing__，可能会创建一个嵌套调用链，这会造成堆栈溢出。这是因为 self[key] 始终通过 __getitem__ 路由，该方法会检查键的存在性，并在失败时调用 __missing__，无论我们是否已经处于 __missing__ 调用之中。为了防止这种情况，您必须在内部查找时使用 dict.__getitem__(self, other_key)，显式捕获 KeyError，或者确保所有依赖关系在方法体内发生任何访问之前都被预填充。
in 操作符与 __missing__ 的交互方式与括号表示法有何不同，这种区别对成员测试至关重要？
in 操作符调用 __contains__，它直接在哈希表中搜索键的哈希，而不调用 __getitem__，这意味着即使键缺失，__missing__ 在成员测试期间也不会被执行。这种行为至关重要，因为它防止了在验证逻辑期间产生副作用；例如，检查 if 'cache' in config: 不应在键不存在时通过 __missing__ 实例化一个新的缓存字典，因为这会在只读检查中污染配置，添加空条目。理解这种区别帮助开发者避免在简单存在性验证中意外生成昂贵的资源或创建无效状态转换。