Python数据类：用基于ID的哈希替代unsafe_hash=True是否安全？

这么做绝对存在严重问题，会直接破坏Python哈希容器（dict、set等）的正常工作逻辑，导致不可预测的bug，具体原因和后果如下：

1. 违反哈希契约的本质影响 #

Python官方明确规定：如果a == b返回True，那么hash(a)必须等于hash(b)。这是哈希容器的核心规则——容器会先通过哈希值快速定位元素所在的槽位，再用==判断是否为同一元素。打破这个规则，相等的对象会被哈希容器当成完全不同的个体，彻底违背直觉。

2. 具体的bug场景 #

举几个典型的异常行为：

• Set成员判断失效：

  s = {p1}
  print(p2 in s)  # 会返回False，但按值相等的逻辑应该返回True
  

  明明两个点值相等，但set会把它们当成不同元素，无法正确识别。

• 字典键匹配失效：

  d = {p1: "test_value"}
  print(d.get(p2))  # 返回None，但按值相等的逻辑应该返回"test_value"
  

  你用p1存了值，却无法通过相等的p2取出，直接破坏字典的基本使用逻辑。

3. 你的需求本身存在矛盾 #

你想要「值相等的对象==返回True，但在字典里作为不同键存储」，这本身就和Python字典的设计逻辑冲突：字典的键唯一性是由__eq__（值相等）和__hash__（哈希一致）共同判定的，只要两个对象==为True，字典就会认为它们是同一个键，后续赋值会覆盖前面的。

4. 正确的应对方案 #

根据你的实际需求二选一：

• 需求一：值相等的对象视为同一实体
  直接使用默认的数据类配置（如果类是不可变的，也可以用frozen=True自动生成安全的哈希），这符合Python的常规用法：

  @dataclass(frozen=True)
  class Point:
      x: int
      y: int
  

  此时p1和p2在字典里会被视为同一个键，这是合理的行为。

• 需求二：不同实例即使值相等也视为不同实体
  修改__eq__方法，让它基于对象实例的id判断相等（回到object类的默认行为），同时保留基于id的哈希：

  @dataclass(eq=False)
  class Point:
      x: int
      y: int
  
      def __eq__(self, other):
          return self is other  # 仅当是同一实例时才相等
  
      def __hash__(self):
          return hash(id(self))
  

  此时p1 == p2会返回False，同时它们可以作为字典的不同键存储，这也符合逻辑，但放弃了值相等的比较。

内容的提问来源于stack exchange，提问作者Rob