hash()拒绝未冻结对象是因为可变对象的哈希值不稳定，破坏字典/集合结构；Python通过将__hash__设为None实现约束，@dataclass(frozen=True)、NamedTuple等提供类型安全的哈希支持。
为什么 hash() 会拒绝未冻结对象
hash() 在 Python 中要求对象是“不可变”的，本质是要求 __hash__ 返回稳定值——而可变对象的哈希值可能随内容改变，破坏字典/集合的底层结构。Python 不强制检查是否真的“不可变”，而是约定：若实现了 __eq__ 且没显式定义 __hash__，则自动设为 None（即不可哈希）。所以“只对 frozen 对象生效”不是 hash() 的内置规则，而是你主动控制的结果。
用 @dataclass(frozen=True) 实现类型安全的哈希对象
这是最直接、类型友好的方式。启用 frozen=True 后，dataclass 自动生成带类型注解的 __hash__，且禁止运行时修改字段（触发 FrozenInstanceError）。
实操建议：
- 必须标注所有字段的类型（如
name: str），否则typing工具（如 mypy）无法校验构造参数类型 - 避免在
__post_init__中修改字段——即使 frozen，该方法仍可执行，但后续赋值会报错 - 若含可变默认值（如
list），必须用field(default_factory=list)，否则运行时报错
示例：
@dataclass(frozen=True)
class Point:
x: int
y: int
p = Point(1, 2)
print(hash(p)) # ✅ 正常返回整数
p.x = 3 # ❌ FrozenInstanceError
手动定义 __hash__ 时如何保持类型安全
手动实现适用于需要自定义哈希逻辑（如忽略某些字段），但容易绕过类型检查。关键点在于：确保 __hash__ 只依赖 __eq__ 所依赖的字段，且这些字段本身是不可变类型。
常见错误现象：
- 字段含
list或dict→ 运行时报TypeError: unhashable type - 字段是自定义类但没实现
__hash__→ 哈希失败 - 用了
__slots__却漏写某个参与比较的字段 →hash()和==行为不一致
正确做法：
- 只对
tuple、str、int等原生不可变类型或已哈希的自定义对象取哈希 - 用
typing.Final标注字段（如id: Final[int]），提示类型检查器该字段不应被重写 - 在
__hash__中显式调用hash((self.a, self.b))，而非hash(self.a + self.b)（后者易冲突）
用 NamedTuple 替代时要注意什么
NamedTuple 天然 frozen 且可哈希，也支持类型注解，但它是类工厂，不是普通类——它的字段是只读属性，没有 __dict__，也不支持继承或自定义 __init__。
使用场景：
- 轻量级、纯数据容器（如配置项、坐标点）
- 需和
typing.NamedTuple配合做静态类型检查
容易踩的坑：
- 定义时用
class X(NamedTuple):形式，别用collections.namedtuple()—— 后者不支持类型注解 - 字段名不能是 Python 关键字（如
class、def），否则生成类失败 - 若字段类型是泛型（如
list[str]），需用typing.List[str]（Py3.9+ 可用内置）
类型安全不是靠“加个 frozen 就完事”，而是让类型检查器能追踪到“这个对象一旦创建，哪些属性永远不变”，并阻止任何可能破坏哈希稳定性的赋值路径。真正难的是嵌套结构——比如一个 frozen dataclass 包含另一个可变对象，这时 hash 依然会崩，但错误发生在运行时而非类型检查阶段。
