前言：一个线上事故引发的内存焦虑
去年我接手了一个量化交易的数据处理服务，核心逻辑很简单——从 Kafka 消费行情数据，解析后丢进内存里的一个定价模型。问题出在那个定价模型上：它要为全市场 5000+ 只股票各自维护一个 OrderBook 对象，每个对象里存几十个档位数据。
上线第二周，运维就来找我了：「你这服务内存涨得比工资还快——跑了三天从 800MB 飙到 3.2GB，再不管 OOM Killer 就来了。」
查了一圈，问题就出在 __dict__ 上。每个 Python 对象默认背着一个字典来存属性——字典本身就是重武器，5000个实例 × 几十个属性 = 内存黑洞。解决方案只加了两行代码：__slots__ = (...)。内存直接降了 60%，GC 停顿也肉眼可见地减少。
这篇文章就来深挖 __slots__ 这个被严重低估的性能特性——它到底怎么工作、能省多少内存、有哪些坑、什么时候不该用。
Python 对象的隐藏成本：__dict__ 到底有多大
先看一个简单的例子：
class OrderBook:
def __init__(self):
self.symbol = "000001.SZ"
self.bid_price = 10.50
self.ask_price = 10.51
self.bid_vol = 10000
self.ask_vol = 8000直觉上这个对象也就存了 5 个字段，内存应该很小。但实际上：
import sys
ob = OrderBook()
print(sys.getsizeof(ob)) # 56 bytes —— 这只是对象本身
print(sys.getsizeof(ob.__dict__)) # 264 bytes —— __dict__ 才是大头每个 Python 实例默认带一个 __dict__ 属性，类型是 dict。而 Python 的 dict 为了快速查找做了大量优化——哈希表、负载因子预留、冲突链——导致一个只有 5 个 key 的字典就占了 264 字节。相比之下，对象本身（PyObject header + ob_type 指针等）才 56 字节。
当你有 10000 个这样的实例时：
# 10000 个实例的内存占用
# 每个实例：56 (obj) + 264 (__dict__) = 320 bytes
# 总计：320 * 10000 = 3,200,000 bytes ≈ 3.05 MB
# 5 个字段的数据量本身才多少？
# 5 * 8 bytes (指针) = 40 bytes
# 有效数据占比：40 / 320 = 12.5%
# 87.5% 的内存都是开销！百分之八十七点五——这就是 Python 对象的真实面目。当你创建大量小对象时，内存开销主要在结构上，不在数据上。
__slots__ 的底层机制
__slots__ 本质上是在告诉 Python 解释器：「这个类的实例只会有这些属性，不要给我配 dict 了，直接用 C 级别的固定偏移量来存取。」
具体来说，当你声明了 __slots__：
- 不创建 __dict__：实例不再有
__dict__属性，属性值直接存储在 PyObject 的固定槽位中 - 属性存取变成数组索引：不再是 hash 查找，而是直接按偏移量 O(1) 读取——类似于 C 结构体的字段访问
- 禁止动态添加属性：
obj.new_attr = 1会直接抛AttributeError
改造后的代码：
class OrderBook:
__slots__ = ('symbol', 'bid_price', 'ask_price', 'bid_vol', 'ask_vol')
def __init__(self):
self.symbol = "000001.SZ"
self.bid_price = 10.50
self.ask_price = 10.51
self.bid_vol = 10000
self.ask_vol = 8000内存对比：
ob = OrderBook()
print(sys.getsizeof(ob)) # 96 bytes —— 一次性搞定，不再有 __dict__
# 之前：56 + 264 = 320 bytes
# 现在：96 bytes
# 降低：70%实测数据：不同方案的内存PK
说再多不如跑一组数据。我用 pympler.asizeof 做了完整的对比（sys.getsizeof 只算浅层，pympler 会递归统计，更接近真实内存）：
from pympler import asizeof
from dataclasses import dataclass
from typing import NamedTuple
# 方案1：普通类
class PlainTrade:
def __init__(self):
self.symbol = "000001.SZ"
self.price = 10.50
self.volume = 1000
self.side = "BUY"
self.order_id = 12345678
self.timestamp = 1721548800.0
self.status = "FILLED"
# 方案2：__slots__
class SlotsTrade:
__slots__ = ('symbol', 'price', 'volume', 'side', 'order_id', 'timestamp', 'status')
def __init__(self):
self.symbol = "000001.SZ"
self.price = 10.50
self.volume = 1000
self.side = "BUY"
self.order_id = 12345678
self.timestamp = 1721548800.0
self.status = "FILLED"
# 方案3：dataclass（不带 slots）
@dataclass
class DCTrade:
symbol: str
price: float
volume: int
side: str
order_id: int
timestamp: float
status: str
# 方案4：dataclass + slots
@dataclass(slots=True)
class DCSlotsTrade:
symbol: str
price: float
volume: int
side: str
order_id: int
timestamp: float
status: str
# 方案5：NamedTuple
class NTTrade(NamedTuple):
symbol: str
price: float
volume: int
side: str
order_id: int
timestamp: float
status: str
# 对比
for name, cls in [("Plain", PlainTrade), ("__slots__", SlotsTrade),
("dataclass", DCTrade), ("dataclass+slots", DCSlotsTrade),
("NamedTuple", NTTrade)]:
inst = cls() if name != "NamedTuple" else NTTrade("000001.SZ", 10.5, 1000, "BUY", 12345678, 1721548800.0, "FILLED")
size = asizeof.asizeof(inst)
print(f"{name:<20}: {size:>6} bytes (单实例)")
跑出来的结果（见下方图表），__slots__ 版本单实例内存仅为普通类的 28%。当实例数量达到 10 万级别时，差异就是 GB 级的。
__slots__ 的性能副作用：属性访问更快了吗？
内存之外还有一个常被忽略的收益——属性访问速度。因为 __slots__ 用描述符和固定偏移量直接存取，跳过了字典的 hash 查找。
import timeit
# 属性读取
plain = PlainTrade()
slots = SlotsTrade()
n = 10_000_000
t_plain = timeit.timeit(lambda: plain.price, number=n)
t_slots = timeit.timeit(lambda: slots.price, number=n)
print(f"Plain class: {t_plain:.4f}s ({t_plain/n*1e9:.1f} ns/op)")
print(f"__slots__: {t_slots:.4f}s ({t_slots/n*1e9:.1f} ns/op)")
print(f"Speedup: {t_plain/t_slots:.2f}x")
我机器上的实测结果：__slots__ 的属性读取比 __dict__ 快 2-3 倍。不过说实话，这点差距在大多数场景下几乎感觉不到——主要收益还是在内存。但当你在热循环里频繁读写属性时（比如逐 tick 更新订单簿），这个差距是有意义的。
踩过的三个坑
坑1：继承链里 __slots__ 不会自动合并
子类不会自动继承父类的 __slots__：
class Base:
__slots__ = ('x',)
class Child(Base):
__slots__ = ('y',) # Child 有 x 和 y 两个 slot
class GrandChild(Base):
pass # GrandChild 有 __dict__！因为没声明 __slots__子类如果没声明 __slots__，它会重新获得 __dict__——父类的 slot 还在，但同时也背上了一个字典。所以要确保整个继承链上的每一层都声明了 __slots__。
坑2：多重继承时的 layout 冲突
两个父类都有 __slots__ 且 slot 布局冲突时，Python 会报 TypeError：
class A:
__slots__ = ('x', 'y')
class B:
__slots__ = ('x', 'z') # 'x' 跟 A 冲突
class C(A, B): # TypeError: multiple bases have instance lay-out conflict
pass这在大型项目中很坑——你引入了一个第三方库的基类，它声明了 __slots__，然后你的类也跟着用 __slots__ 就炸了。解决方式是避免在多重继承中用 __slots__，或者只用单继承。
坑3：weakref 需要显式留坑
如果你想对 __slots__ 类的实例使用 weakref，必须在 __slots__ 中显式加上 'weakref'：
class SlotWithWeakref:
__slots__ = ('data', '__weakref__')
obj = SlotWithWeakref()
import weakref
ref = weakref.ref(obj) # OK
class SlotWithoutWeakref:
__slots__ = ('data',)
obj2 = SlotWithoutWeakref()
ref2 = weakref.ref(obj2) # TypeError这个问题在用到缓存库（如 functools.lru_cache 或某些 ORM）时容易触发——它们内部可能对对象创建弱引用。
什么时候该用 __slots__？
| 场景 | 推荐 | 原因 |
|---|---|---|
| 创建大量小对象（>10k） | ✅ 强烈推荐 | 内存节省显著，GC压力降低 |
| 热循环中读写属性 | ✅ 推荐 | 属性访问快2-3x |
| 数据类 / DTO / 消息对象 | ✅ 推荐 | 属性集合固定，正合__slots__的设计目标 |
| dataclass | ✅ 推荐 | 直接用 @dataclass(slots=True)，Python 3.10+ |
| 仅几个实例的类 | ❌ 不需要 | 省不了几KB，反而增加限制 |
| 需要动态属性的类 | ❌ 不能用 | __slots__禁止动态添加属性 |
| ORM 模型 | ⚠️ 谨慎 | 部分ORM依赖__dict__做脏检查 |
| 多重继承场景 | ❌ 容易出问题 | slot layout 冲突 |
生产环境实战：量化交易订单簿的完整优化
回到开头提到的那个量化交易服务。最终优化后的 OrderBook 结构如下：
class PriceLevel:
"""单个档位"""
__slots__ = ('price', 'volume', 'order_count')
def __init__(self, price: float, volume: int, order_count: int = 0):
self.price = price
self.volume = volume
self.order_count = order_count
class OrderBook:
"""订单簿 — 每只股票一个实例"""
__slots__ = ('symbol', 'bids', 'asks', 'timestamp',
'total_bid_vol', 'total_ask_vol')
def __init__(self, symbol: str):
self.symbol = symbol
self.bids: list[PriceLevel] = []
self.asks: list[PriceLevel] = []
self.timestamp = 0.0
self.total_bid_vol = 0
self.total_ask_vol = 0
def update(self, side: str, levels: list[tuple[float, int]]):
"""按档位更新订单簿"""
target = self.bids if side == 'BUY' else self.asks
target.clear()
for price, vol in levels:
target.append(PriceLevel(price, vol))
# ... 重新计算汇总量
# 创建全市场订单簿
books = {symbol: OrderBook(symbol) for symbol in SYMBOLS} # 5000+ 只股票
优化效果：
优化前（普通类 OrderBook + PriceLevel）：
5000 个 OrderBook + 5万个 PriceLevel ≈ 120 MB
优化后（__slots__ 版）：
5000 个 OrderBook + 5万个 PriceLevel ≈ 48 MB
节省：60%
GC full collection 频率：从每30秒一次降到每5分钟一次
用 tracemalloc 做对比快照验证：
import tracemalloc
tracemalloc.start()
# ... 创建对象 ...
snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics('lineno')
for stat in top_stats[:3]:
print(stat)
顺便说一句，Python 3.10 以后 dataclass(slots=True) 是真香——既保留了 dataclass 的便捷（自动 init、repr、eq），又自动应用了 slots 的内存优化。如果你在用 3.10+，无脑加 slots=True 就行了。
FAQ
Q: __slots__ 和 dataclass(slots=True) 有什么区别？
@dataclass(slots=True) 是 Python 3.10 引入的，本质上是自动为 dataclass 生成 __slots__——你不需要手动列出所有字段名。但它同时保留了 dataclass 的自动方法生成（__init__、__repr__、__eq__）。如果你的 Python ≥ 3.10，优先用 slots=True。
Q: __slots__ 会让对象创建速度变快吗？
会，但不多。省掉了 __dict__ 的初始化和内存分配，创建 slotted 对象大约快 10-20%。主要收益还是内存和属性访问速度。
Q: 用了 __slots__ 还能用 pickle 序列化吗？
可以。pickle 对 __slots__ 类有原生支持，不需要额外处理。copy.copy() 和 copy.deepcopy() 也都正常工作。
Q: __slots__ 加了以后还能用 @property 吗？
能，完全没问题。__slots__ 中的属性名仍然可以被 @property 覆盖为描述符——只要 property 的名字跟 slot 名一致就行。
总结
__slots__ 是 Python 里性价比最高的性能优化手段之一——两行代码，零侵入，内存直降 60%，属性访问快 2-3 倍。它特别适合数据密集型场景：消息对象、DTO、缓存条目、Model 层实体、批量数据处理中间结果。
但别滥用。一个只有三五个实例的类加了 __slots__ 纯粹是给自己添堵——动态属性的灵活性没了，DEBUG 时看不到 __dict__ 也不方便。在合适的地方用，它就是银弹；到处乱套，就是镣铐。
如果你的 Python ≥ 3.10，建议把项目中所有 @dataclass 都加上 slots=True——几乎零成本的性能收益，为什么不呢？
相关文章推荐
- Python 性能剖析三件套：py-spy、Scalene、memray 实战对比——一次接口优化从 80ms 到 8ms 的全记录
- Python 生产环境内存泄漏排查实战——从发现到修复的完整复盘
- Python Pandas 性能优化实战：让 DataFrame 操作快 10 倍的 7 个技巧
- Python 并发编程深度实战：为什么你的多线程比单线程还慢——GIL 原理与最优并发策略选择
📎 推荐阅读：Python memoryview 零拷贝数据处理实战 — 用 buffer protocol 让切片操作快 30 倍，含量化数据处理完整案例。
🆕 新文推荐：Python @lru_cache 不是银弹：缓存加速 50,000 倍时的三个致命陷阱——一行代码快 50,000 倍？先避开这三个坑再说。
📖 相关阅读：Python itertools 惰性管道实战 — 用生成器管道替代千行循环，百万级数据处理快 3 倍、内存减半。
想了解 slots 为什么能省内存、底层到底怎么工作的，可以看这篇 Python 描述符深度实战：每个 slot 本质就是一个成员描述符，这是省内存背后的真正机制。
如果你也在做高频对象创建的性能优化，推荐这篇：Python 对象池深度实战：CPython 内存分配器与 slots 复用技巧。
⚠️ 免责声明：本文中的性能数据基于 Python 3.12 + Ubuntu 24.04 实测，不同环境/版本下数值可能有差异，但趋势一致。投资有风险，代码更有风险。