frozen dataclass 是 Python 标准库 dataclasses 模块中一个容易被低估的特性。很多人只知道加上 frozen=True 之后属性就不能改了，却没细想过这层“不可变”到底是怎么实现的，以及它和 NamedTuple、attrs 的冻结模式有什么差别。理解它的底层机制，能帮助你在配置对象、值对象（Value Object）以及需要作为字典键或集合元素的场景中做出正确选型。
frozen=True 到底冻结了什么
先看一个最简单的例子。定义一个带 frozen=True 的数据类，然后尝试修改属性：
from dataclasses import dataclass
@dataclass(frozen=True)
class Point:
x: float
y: float
p = Point(1.0, 2.0)
p.x = 10.0 # 这里会抛出 FrozenInstanceError运行上面这段代码，Python 会在赋值那一行抛出 dataclasses.FrozenInstanceError，它是 AttributeError 的子类，所以你可以用常规的异常捕获方式处理它。
那这个拦截是怎么发生的？关键在于 __setattr__ 和 __delattr__ 两个魔术方法。dataclass 装饰器在检测到 frozen=True 时，会在生成的类上写入这两个方法，任何属性赋值或删除操作都会先经过它们，然后直接抛异常。也就是说，这并不是把属性变成了某种只读内存，而是一种运行时的行为拦截。
这也解释了一个常见的困惑：为什么用 object.__setattr__ 绕过拦截还是能改？因为这个机制只覆盖常规的赋值路径，你完全可以手动调用底层方法打破冻结，Python 的一贯哲学是“我们都是成年人”，不追求强制防御。看下面这个例子：
object.__setattr__(p, 'x', 99.0) print(p.x) # 输出 99.0，冻结被绕过了
冻结带来的最大红利：可哈希
frozen=True 有一个常被忽略的副作用——它会让 dataclass 默认生成安全的 __hash__。普通 dataclass 因为 eq=True 默认会把 __hash__ 设为 None，实例放进集合或当字典键会直接报 TypeError。而冻结类因为属性不会变，哈希值天然稳定，可以放心地用于 set 和 dict。
@dataclass(frozen=True)
class Color:
r: int
g: int
b: int
palette = {Color(255, 0, 0): "红", Color(0, 255, 0): "绿"}
print(palette[Color(255, 0, 0)]) # 输出 红这里有个前提必须强调：所有字段本身也要是可哈希的。如果某个字段是 list 或 dict 这类可变容器，__hash__ 在调用时仍会抛 TypeError。解决办法是把字段类型换成 tuple 或 frozenset，这符合不可变设计的整体思路——外层冻结了，内层数据也应该跟着冻结，否则哈希安全就是空谈。
另外要注意可变默认值的问题。普通 dataclass 禁止使用 list 作为字段默认值，而冻结类同样如此，你需要用 field(default_factory=tuple) 来给出不可变的默认构造。这一点上 frozen 和非 frozen 的约束是一致的，冻结并不会自动帮你处理可变默认值的坑。
想在初始化时校验或加工字段怎么办
冻结类带来的第一个麻烦是：你没法在 __init__ 之后写 self.xxx = ...，常规的初始化后加工写法会直接报错。官方推荐的方案是使用 __post_init__ 配合 object.__setattr__：
from dataclasses import dataclass
@dataclass(frozen=True)
class Rectangle:
width: float
height: float
area: float = 0.0
def __post_init__(self):
if self.width <= 0 or self.height <= 0:
raise ValueError("宽和高必须为正数")
object.__setattr__(self, 'area', self.width * self.height)
r = Rectangle(3.0, 4.0)
print(r.area) # 输出 12.0这种写法不算优雅，但它是官方文档明确给出的模式。如果你觉得到处写 object.__setattr__ 太啰嗦，可以在类里封装一个私有辅助方法，统一处理派生字段的写入。
另一个思路是放弃在 __post_init__ 里加工，改为属性派生：把 area 定义成 @property，每次访问时实时计算。两种方案各有取舍，property 方案避免了冻结冲突，但每次访问都要重新计算；__post_init__ 方案一次算好存下来，适合计算成本高的派生值。
与 NamedTuple、attrs 的对比及继承陷阱
NamedTuple 也是常见的不可变数据结构选择，它本质是 tuple 的子类，优势是省内存、可通过索引访问、可解包；劣势是继承 tuple 后无法和普通类自由混用，字段也不能带复杂逻辑。frozen dataclass 则是真正的类，可以加方法、用继承、配合抽象基类。如果你需要的是“带行为方法的值对象”，frozen dataclass 更合适；如果只是简单的数据聚合，NamedTuple 更轻。
第三方库 attrs 的 @attr.s(frozen=True)（或新式写法 @define(frozen=True)）提供类似能力，并且在 slots 支持、校验器等方面比标准库更早成熟。Python 3.10 之后标准库的 slots=True 参数已经能和 frozen=True 组合使用，进一步节省内存，二者配合是目前很推荐的生产写法：
@dataclass(frozen=True, slots=True)
class Config:
host: str
port: int = 8080最后提一个继承相关的陷阱：如果父类是冻结的，子类也必须显式声明 frozen=True，否则子类实例就会变回可变对象，而且不同冻结状态的类之间混用继承会直接抛 TypeError。反过来，父类不冻结、子类想冻结是允许的。团队协作时建议统一约定，要么全链路冻结，要么干脆不用，避免出现半冻半动的混乱状态。
总结一下，frozen dataclass 的“不可变”是运行时拦截而非语言级强制，它的核心价值在于哈希安全和防御性编程。写配置对象、领域模型中的值对象，或者需要作为缓存键的数据，都值得默认加上 frozen=True；而频繁就地修改的热路径对象则不适合，因为每次“修改”都要重建实例，代价不小。
Python frozen dataclass不可变数据类dataclass修改时间：2026-09-07 02:24:32