Python 3中显式定义__eq__会自动将__hash__设为None，以防止可变对象被用作字典键或集合元素；若需哈希，必须基于不可变字段实现__hash__，且与__eq__逻辑一致。
重写 __eq__ 后 __hash__ 被自动设为 None
Python 3 的设计规则是：只要类显式定义了 __eq__，解释器就认为该类的实例“可能可变”，于是**自动将 __hash__ 设为 None**。这不是警告，是硬性禁用：
- 此时尝试把实例放进
set、作为dict的键、或传给hash()，会立刻报TypeError: unhashable type - 哪怕你没动
__hash__，它也不再继承object.__hash__（即基于id的默认哈希） - 这个行为无法绕过——不是忘了写，是 Python 主动把它“关掉”了
__hash__ 和 __eq__ 必须逻辑一致
哈希表（dict/set 底层）依赖两步定位：
- 先调
hash(obj)算出桶号 - 再在桶内遍历，对每个候选对象调
obj == candidate做最终确认
如果只重写 __eq__ 而不改 __hash__，就会出现：
-
a == b返回True（字段相同） - 但
hash(a) != hash(b)（因为__hash__还是默认的id基础） - 结果：
a in {b}是False，{a, b}长度为 2，{a: 1, b: 2}是两个键
怎么写安全的 __hash__？只基于不可变字段
核心约束只有一个：所有参与 __eq__ 判断的字段，也必须参与 __hash__ 计算；且这些字段在对象生命周期内不能被修改。
立即学习“Python免费学习笔记（深入）”；
- 推荐写法：
def __hash__(self): return hash((self.x, self.y))—— 元组天然不可变，hash安全 - 如果类本身可变（比如有
self.cache或self.updated_at），别强行哈希；要么冻结字段（@dataclass(frozen=True)），要么设__hash__ = None显式拒绝 - 绝对不要在
__hash__中调用方法、读取属性 getter、或引入随机数/时间戳——哈希值必须稳定
最容易被忽略的细节：字段可变性比代码写法更关键
即使你写了 __hash__ = lambda self: hash(self.x) 且 __eq__ 也只比 x，只要 self.x 后续被修改，哈希表就失效：
- 对象插入
set后，self.x从1改成2 - 再查
obj in my_set可能返回False，因为桶位置已错 - 这种 bug 很难复现，往往出现在长期运行的服务中
所以真正决定能否哈希的，不是你有没有写 __hash__，而是你的对象是不是事实上的值对象（value object）——字段初始化后就不再变化。
