Python dataclasses slots 与继承字段的设计

我第一次把一个长期存活的数据对象改成 @dataclass(slots=True) 时，真正卡住的不是装饰器语法，而是继承之后“字段在哪里、属性能不能再扩展、为什么某些字段没有出现在子类的 __slots__ 里”。这几个问题如果混在一起，代码很容易变成能运行但难维护的模型。

这篇文章把范围收窄到 Python dataclasses 的 slots 与继承字段设计：先说明能力变化，再给出基类和子类的写法，最后把默认值顺序、重复槽位、__dict__ 和弱引用的边界放到一张检查清单里。

官方文档：https://docs.python.org/3/library/dataclasses.html

最稳妥的原则是：用 dataclasses.fields() 读取完整字段，用 slots=True 管理实例属性空间；不要把子类的 __slots__ 当成继承字段清单，也不要用 slots 代替构造函数和继承设计。

先把 slots 的边界说清楚

slots=True 不只是给原来的类加一个字符串属性。dataclasses 会根据字段生成槽位并返回新的类对象，实例通常不能再随意写入未声明的属性；如果父类已经提供了普通 __dict__，子类仍可能保留动态属性能力。因此，slots 的目标是约束实例布局，而不是自动解决所有内存或继承问题。

字段元数据和存储布局应该分开看。fields(Account) 或 fields(AdminAccount) 才适合回答“模型有哪些字段”；AdminAccount.__slots__ 只回答“这个类自己需要声明哪些槽位”。Python 3.11 起，如果字段名已经在父类槽位中，生成器会避免在子类重复声明它，所以直接遍历 __slots__ 可能漏掉继承字段。

为什么继承字段首先是构造函数问题

dataclass 会把基类字段和子类字段合并到生成的 __init__() 中，字段顺序仍然影响参数顺序。继承时最容易遇到的限制是：带默认值的字段之后不能再出现无默认值字段。这个限制不仅存在于一个类内部，也会跨越继承层级。

from dataclasses import dataclass

@dataclass(slots=True)
class Account:
    # 基类放稳定且必需的身份字段
    account_id: int
    region: str = "cn"

@dataclass(slots=True)
class AdminAccount(Account):
    # 子类新增字段也要遵守合并后的默认值顺序
    role: str = "operator"
    audit_enabled: bool = True

admin = AdminAccount(account_id=7, role="owner")
print(admin.account_id, admin.region, admin.role, admin.audit_enabled)

这个布局的好处是基类的必填字段位于默认字段之前，子类只继续追加带默认值字段。若基类已经有默认字段，子类又想新增必填字段，通常会得到 TypeError；此时应重新划分必填字段层级，或者把新增字段设计成关键字参数，而不是靠改写 __slots__ 绕过构造函数契约。

处理重复字段与实例扩展

继承设计里有三个“看起来都能赋值，实际含义不同”的边界：

• 同名字段：子类重新声明父类字段会影响字段定义和默认值，应先确认这是有意覆盖还是命名冲突。
• 重复槽位：不要手写与 dataclass 生成规则冲突的 __slots__；父类已经存在的槽位不应在子类再次当作新字段处理。
• 动态属性：如果继承链上某一层有普通类或显式 __dict__，实例仍可能接受未声明属性，slots 的约束就不再是全链路约束。

我通常会把“是否允许扩展”写成模型设计的一部分：严格数据对象使用所有相关层级的 slots=True；需要插件式附加属性时，明确保留 __dict__，并在类文档中写清楚，而不是让它因为某个非 dataclass 父类悄悄出现。

需要弱引用时单独打开 weakref_slot

slots 实例默认不一定能被 weakref.ref() 引用。如果缓存、观察者或生命周期管理确实需要弱引用，可以在同时启用 slots=True 时设置 weakref_slot=True。单独设置 weakref_slot=True 而没有 slots 是错误用法，因为 __weakref__ 本身就是槽位的一部分。

from dataclasses import dataclass
import weakref

@dataclass(slots=True, weakref_slot=True)
class Session:
    # token 是实例字段；weakref_slot 只提供弱引用入口，不增加业务字段
    token: str

session = Session(token="temporary")
reference = weakref.ref(session)
print(reference() is session)

这里的重点不是“所有 dataclass 都应该开启弱引用”，而是把需求和布局分开：不用弱引用就不要增加槽位；需要弱引用就把选项放在类型定义处，让读代码的人能看到实例生命周期契约。

用 fields()、槽位集合和属性赋值做最小检查

发布前或重构后，我会做三类轻量检查：字段元数据是否包含继承字段；类本身的槽位是否只承担存储布局；一个未声明属性是否按预期被拒绝或允许。下面的代码只检查设计契约，不依赖对象大小等容易受解释器实现影响的数值。

from dataclasses import fields

def describe_model(model_type: type) -> None:
    # fields() 负责完整字段视图，不能用 __slots__ 替代
    field_names = [item.name for item in fields(model_type)]
    # 只读取当前类声明的槽位，避免把它误当成继承字段全集
    own_slots = tuple(getattr(model_type, "__slots__", ()))
    print("fields:", field_names)
    print("own slots:", own_slots)

describe_model(AdminAccount)

如果需要检查动态属性边界，可以在测试中对一个实例尝试写入明确的测试字段，并把“允许”或“抛出 AttributeError”写成预期，而不是把异常吞掉。这样既能发现继承链里意外带入的 __dict__，也不会把某个 Python 版本的内部布局当成业务事实。

一张设计速查表

常见相关问题

slots=True 会自动让所有继承层都没有 __dict__ 吗？

不会。要看继承链上是否存在普通类或显式的 __dict__。如果严格禁止动态属性，需要逐层检查类设计，而不是只看最末子类的装饰器参数。

为什么 fields() 比 __slots__ 更适合做字段序列化？

因为 fields() 面向 dataclass 字段元数据，能够表达继承字段；__slots__ 面向实例布局，可能只包含当前层声明的槽位，也可能包含特殊槽位。

weakref_slot=True 能单独使用吗？

不能。它要求同时启用 slots=True，否则应改回普通 dataclass 或重新评估生命周期管理方式。

对我来说，slots 继承设计最有价值的改变是把“字段模型”和“实例布局”拆开讨论：构造函数顺序解决初始化契约，fields() 解决字段观察，slots 解决属性空间，weakref_slot 解决弱引用能力。四者各自有边界，模型就不会因为追求紧凑而失去可读性。