本文由 千趣源码 – qianqu 发布，转载请注明出处，如有问题请联系我们！Python的“不可见契约”：从对象ID、哈希与身份比较说起

在python初学者眼中，`==` 是相等，`is` 是同一；`id()` 返回内存地址，`hash()` 生成散列值——这些概念常被当作孤立的知识点机械记忆。但若深入观察Python解释器的底层行为，会发现它们共同构成了一套精妙而沉默的“不可见契约”：一套关于对象身份、稳定性与语义一致性的隐性协议。这套契约不写在文档首页，却贯穿于字典查找、集合去重、缓存机制乃至`@lru_cache`的每一次命中判断之中。 让我们从一个反直觉的实验开始： ```python a = 1000 b = 1000 print(a is b) # False（在多数CPython交互环境中） c = 100 d = 100 print(c is d) # True ``` 为什么小整数“复用”，大整数却各自独立？这不是优化，而是契约的起点——CPython为`[-5, 256]`范围内的整数预分配单例对象，确保其`id()`恒定、`hash()`恒定、且`is`恒为真。这并非语言规范强制，而是实现层面为保障**哈希稳定性**与**身份一致性**所作的务实约定：若两个相等的整数拥有不同`id()`，则无法安全地用作字典键——因为字典依赖`hash()`定位桶，再用`is`或`==`确认键匹配。若`hash(100)`在两次调用中结果不同，或`100 is 100`偶然为假，整个哈希表结构将瞬间崩塌。 更微妙的是字符串。执行`e = "hello"; f = "hello"`，`e is f`通常为真；但若`f = "hel" + "lo"`，结果仍为真；可一旦涉及运行时拼接（如`g = "hel" + input("lo: ")`），即使内容相同，`g is e`也必为假。这里起作用的不是“字符串驻留”（string interning）本身，而是契约对**可预测性**的要求：编译期确定的字面量可安全驻留，因其实例化时机、生命周期与哈希值完全可控；而动态构造的字符串若强行驻留，则可能引发不可预测的内存泄漏或跨模块身份冲突——契约在此划出边界：可驻留，但不强制；稳定优先，便利次之。 这一契约甚至悄然塑造了Python的设计哲学。考虑`None`：它既是单例，又是`hash(None)`的固定返回值（即0），且所有`None is x`仅当`x`确为`None`时为真。这种三重锁定（唯一ID、固定哈希、严格身份）使其成为最安全的占位符——`dict.setdefault(key, None)`绝不会因`None`的哈希漂移而失效。反观自定义类：若未重写`__hash__`，默认继承`object.__hash__`，其返回值基于`id()`；但若同时重写了`__eq__`却不重写`__hash__`，Python会自动将`__hash__`设为`None`，使实例不可哈希。这是契约的主动干预：它拒绝容忍“相等却哈希不同”的逻辑矛盾，宁可让对象退出哈希容器生态，也不妥协一致性。 有趣的是，契约在协程与异步对象中显出新维度。`asyncio.Task`对象的`id()`在其生命周期内绝对不变，但`hash(task)`却可能随状态变更而变化（因默认哈希基于`id`，而`id`不变）；然而，你永远不应将`Task`用作字典键——因为任务状态可变，违背哈希对象“不可变性”隐含前提。契约在此升维：它不仅要求技术参数稳定，更要求**语义稳定性**。一个对象能否参与哈希运算，取决于其设计意图是否承诺“值语义恒定”，而非仅看`id()`是否固定。 理解这套不可见契约，能解构许多“魔法”。`@lru_cache`为何要求参数可哈希？因为它将调用签名序列化为元组，再以该元组为键缓存结果——若参数哈希值漂移，缓存将彻底失效。`dataclass(frozen=True)`为何禁止修改字段？冻结不仅是语法糖，更是向契约提交的稳定性声明：它保证`__hash__`可安全生成，且后续所有`==`比较与`hash()`调用保持逻辑自洽。 Python从不宣称自己是“纯函数式语言”，但它用`id`、`hash`、`is`与`==`四者精密咬合的齿轮，默默运转着一条铁律：**可预测的身份，是可信赖的抽象之基石。** 当你写下`if obj is None:`，你调用的不仅是一个比较操作，更是对整个契约体系的信任投票——而这，正是Python在简洁表象之下，最坚韧的工程脊梁。