深入理解 Python __slots__：内存优化原理与实践指南

一、从一个常见误区说起：实例属性并不“免费”

很多人初学 Python 时，默认类的实例就是一个可以随意扩展的容器：obj.xxx = 1 随手一写就能生效。这种灵活性来自每个实例自带的 __dict__——一个真正的字典对象，专门负责存放实例属性。

字典带来的灵活性是有代价的：

• 内存开销：字典本质是哈希表，为了保证查找效率与平滑扩容，会预留额外的桶数组空间。即便只存两三个属性，字典对象本身也要占去可观的内存。当系统需要创建数十万甚至上百万个小对象时，“属性容器”的开销可能反超业务数据本身。
• 访问开销：每次属性读写都要经过一次哈希查找与冲突处理，单次耗时不长，但在高频访问路径上会累积成可观测的成本。

__slots__ 正是针对这两个痛点给出的语言级方案：用一张在设计期就确定的“属性清单”，换取更紧凑的内存布局和更直接的属性访问路径。

二、slots 的工作机制：从“字典”到“槽位”

2.1 基本用法

class Point:
    __slots__ = ("x", "y")
    def __init__(self, x, y):
        self.x = x
        self.y = y
p = Point(1, 2)
print(p.x, p.y)   # 1 2
p.z = 3           # AttributeError：不允许动态新增属性
p.__dict__        # 同样抛出 AttributeError：实例没有属性字典

2.2 解释器在背后做了什么

在类定义阶段，解释器会扫描 __slots__ 声明，并完成三件事：

1. 为每个名字创建描述符。类身上会多出与槽位同名的描述符对象，负责属性的读写与校验，并记录该属性在实例结构中的固定偏移位置。
2. 取消实例 __dict__ 的自动分配。实例不再携带字典，属性值直接存放在对象内部一段固定大小的连续区域中，布局上更接近 C 语言的结构体。
3. 约束属性集合。任何未声明的属性赋值都会在运行时立即失败——错误暴露得越早，排查成本越低。

从访问路径看，普通实例属性要走“查哈希表”的流程；而槽位属性由描述符按固定偏移直接定位，省去了哈希计算与可能的扩容重排，这也是它访问更快的原因。

三、收益有多大：内存与速度的分析

3.1 内存对比的测量方法

普通对象的开销必须把属性字典一起计入，单独测量实例本体没有意义。示意代码如下（具体数值随解释器版本不同而变化，建议在目标环境实测）：

import sys
class WithDict:
    def __init__(self):
        self.a = 1
        self.b = 2
class WithSlots:
    __slots__ = ("a", "b")
    def __init__(self):
        self.a = 1
        self.b = 2
d = WithDict()
s = WithSlots()
# 普通实例的开销 = 实例本体 + 属性字典
print(sys.getsizeof(d) + sys.getsizeof(d.__dict__))
# 槽位实例没有属性字典，只剩对象本体
print(sys.getsizeof(s))

几个要点：

• 实际差值取决于属性数量、解释器版本以及是否保留 __weakref__ 等，总体趋势是槽位版本显著更小；
• 只有当实例数量达到“海量”量级（通常在数万以上）时，绝对收益才有工程价值；几十个对象使用 slots 意义不大；
• 收益不止“省掉一个字典”：实例结构从“对象头 + 指针 + 字典”变为“对象头 + 连续槽位”，对象整体更紧凑，对 CPU 缓存也更友好，在海量对象遍历场景中往往有附加收益。

3.2 速度收益

属性访问省去哈希查找，通常能带来一定提升，但幅度与属性数量、访问模式（读多写少、是否处于热点循环）密切相关。结论应当来自对自己代码的基准测试，而不是照搬他人数据。

四、进阶用法与继承规则

4.1 需要保留动态能力时：显式声明 dict

class Hybrid:
    __slots__ = ("x", "__dict__")   # 固定槽位 + 动态字典并存

同理，若对象需要被弱引用管理（如缓存、对象池），且没有基类提供支持，需要显式加入 "__weakref__"：

class Cacheable:
    __slots__ = ("key", "__weakref__")

4.2 继承场景的三条关键规则

1. 父类没有 slots，子类声明了效果也大打折扣。父类构造的实例布局中已包含 __dict__，子类的槽位只是附加优化。要让优化贯穿继承链，每一层都要声明 __slots__（不需要新属性的子类写 __slots__ = () 即可）。
2. 槽位不要跨层重复声明。子类重复声明父类已有的槽名，会造成描述符遮蔽，轻则冗余浪费，重则出现难以察觉的取值异常，属于典型“坑”。
3. 多重继承受限。多个父类都带非空 __slots__ 时，会因实例布局冲突而直接报错。实践中应保证继承链上只有一个非空槽位来源，其余父类要么不声明，要么声明为空元组。

4.3 与类变量的冲突

类创建阶段就会校验：如果类体中已存在与槽同名的类属性（方法、默认值等），会抛出 ValueError。因此“槽位 + 同名类属性充当默认值”的写法行不通，默认值应放到构造函数或工厂函数中处理。

4.4 标准库工具的配合

• 标准库的数据类装饰器在较新版本中支持一键开启槽位优化（@dataclass(slots=True) 风格的参数），可兼得声明式定义与紧凑布局；
• 对于只读的记录型数据，标准库的命名元组同样具备紧凑、不可动态扩展的特性，可作为轻量替代方案。

五、常见陷阱清单

1. 动态属性彻底失效。依赖运行时挂属性的写法（打补丁、按需缓存）会直接报错；若代码中大量存在 vars(obj)、obj.__dict__.update(...) 这类内省操作，需要先评估改造范围。
2. 序列化与拷贝需要关注。现代解释器的默认序列化协议已能正确处理纯槽位对象，但一旦自定义了状态导出/恢复逻辑，就要记得遍历槽位收集数据：

def __getstate__(self):
    return {name: getattr(self, name) for name in type(self).__slots__}

1. 忘记在子类续写声明。只要有一层子类漏写 __slots__，实例就会重新带上 __dict__，优化静默失效，且不会有任何报错提醒。
2. 继承内置变长类型受限。从 int、bytes、tuple 这类变长内置类型派生时，非空槽位声明不被支持。
3. 类之间转换受限。给实例动态更换 __class__ 时，只有槽位布局完全一致的两个类才能成功，否则抛出布局冲突错误。
4. 调试与元编程工具兼容性。部分依赖实例字典做内省的通用工具（如某些调试探针、字段追踪逻辑）对槽位对象支持不完整，引入前应在真实链路上验证。

六、适用场景判断：什么时候值得用

推荐使用：

• 海量短生命周期小对象：解析器产生的词法/语法节点、图与树的节点、批处理中的记录载体、会话或连接池中的轻量状态对象；
• 属性集合在设计期完全固定、不需要运行期扩展的数据结构；
• 对象数量巨大、且内存占用已成为瓶颈的服务，例如高并发在线推理、日志聚合、缓存层等云端典型负载。

不建议使用：

• 实例数量有限、以业务表达为主的普通领域模型——收益微小，却牺牲了灵活性并增加继承链维护成本；
• 处于快速迭代期、字段频繁增删的数据模型；
• 大量依赖动态属性、元编程或内省逻辑的框架层代码。

一句话决策：先用性能分析确认“海量小对象 + 内存瓶颈”两个条件同时成立，再引入 __slots__；否则优先保持代码的灵活性。

七、总结

__slots__ 的本质是一次“用灵活性换资源”的交换：以固定的属性清单取代每实例字典，换来更小的内存占用、更直接的访问路径和更早的错误暴露。它的价值高度依赖场景——在百万级小对象场景中是立竿见影的优化手段，在普通业务类中则可能变成负资产。掌握继承链逐层声明、__dict__/__weakref__ 的显式保留、类变量冲突校验与序列化适配这几个关键点，就能在生产环境中安全、可控地享受它带来的收益。