Python小对象内存持续上涨主因是pymalloc内存池碎片化而非泄漏：不同尺寸小对象释放后Block无法合并，Pool无法归还OS；优化核心是复用容器、用__slots__减少开销、join替代+=、手动触发gc。
Python海量小对象导致内存持续上涨却查不到泄漏对象，根本不是“泄露”，而是pymalloc在512字节以下的内存池里把空闲块打散了，Arena卡住不还给系统——优化核心是减少新分配、复用已有结构、避开默认对象开销。
小对象为什么在pymalloc里变成碎片
pymalloc把≤512B的对象按固定尺寸（8B/16B/32B/…/512B）切分成Block，塞进4KB的Pool，再装进256KB的Arena。问题出在：你循环创建不同尺寸的小对象（比如{}、[]、"abc"、MyClass()），它们可能落在同一Pool但Block地址不连续；一旦释放，这些空闲Block无法合并；整个Pool必须等所有Block都空才能归还OS。结果就是RSS涨得快，tracemalloc却看不到新增对象。
- 典型诱因：
for i in range(n): d = {}; d['k'] = i—— 每次都申请新Block，旧dict的哈希表桶、预分配缓冲区残留在不同页 - 字符串
+=每轮生成一个新str对象，大量8–256B区间对象快速进出，加剧内部碎片 -
list.append()动态扩容时会申请新Block，旧缓冲区若未被复用就成碎片源
复用容器比反复新建更治本
清空重用能保住底层缓冲区，避免重复向pymalloc要Block，尤其适合结构稳定、尺寸波动不大的场景。
- 用
my_list.clear()代替my_list = []：保留原list的底层数组缓冲区 - 用
my_dict.clear()代替my_dict = {}：避免重建哈希表，减少entry对象分配 - 若键集合已知且固定，可预分配
dict.fromkeys(keys)，减少后续resize - 注意：如果清空后追加量远超原容量（如从10项扩到10万项），缓冲区仍会扩容，此时复用收益下降
__slots__对自定义类有效，但有硬约束
__slots__让实例从带__dict__的动态结构变成紧凑C结构体，单实例内存降30–50%，更重要的是砍掉dict哈希表扩容链——那是pymalloc里最碎的源头之一。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 必须声明为字符串元组：
__slots__ = ('x', 'y')，写成列表或单个字符串会静默失效 - 继承链上每一级都要单独声明，父类写了
__slots__而子类没写 → 子类自动重建__dict__ - 字段名必须和赋值完全一致，
self.x_却在__slots__里写'x'→ 运行时报AttributeError - 别和
@dataclass(slots=True)混用，后者已内置优化，手动加__slots__反而出错
字符串拼接和GC时机需要手动干预
+=拼接每轮都造新str，是pymalloc小对象池的高频污染源；而GC默认靠分配计数触发，对突发批量对象不敏感，容易让碎片滞留数秒。
- 批量拼接一律用
''.join(parts)，底层C实现只分配一次目标内存 - 流式构建用
io.StringIO，其内部缓冲区可复用，避免反复malloc/free - 在批处理函数末尾明确调用
gc.collect(0)，强制清理第0代，成本低见效快 - 若存在已知循环引用（如回调绑定、闭包捕获），关键路径后调用
gc.collect(1)，避免滞留到老年代
真正难的不是知道该用clear()或__slots__，而是得判断哪些对象生命周期长、哪些短，哪些能复用、哪些必须新建——比如解析JSON返回的dict，你没法加__slots__，但可以批量复用同一个dict实例并clear()；又比如日志中临时拼接的str，join未必来得及，这时io.StringIO才是更贴近真实负载的选择。
