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 依然会崩，但错误发生在运行时而非类型检查阶段。