__slots__对字典本身无效，它只作用于类实例的属性存储；想优化大型字典内存，得换思路——用紧凑键、预分配、生成器或替代结构。
直接说结论：__slots__ 对字典本身无效，它只作用于类实例的属性存储；想优化大型字典内存，得换思路——用紧凑键、预分配、生成器或替代结构。
__slots__ 为什么对 dict 没用？
很多人看到 __slots__ 能省 40%~50% 内存，就以为能套在 dict 上。但 dict 是内置类型，你不能给它加 __slots__；就算你继承 dict 并定义 __slots__，Python 也不会禁用其内部的 __dict__（它根本没这个东西），更不会压缩哈希表结构。
常见错误现象：
- 写
class MyDict(dict): __slots__ = []，结果内存完全没变化 - 误以为
__slots__能让{'key': 'value'}更小——其实它只影响你自己写的类实例，比如User对象里存的字段
真正能压缩大型字典内存的 3 种做法
Python 3.6+ 的 dict 本身已改用紧凑结构（键值分离 + 稀疏索引表），但你仍可通过以下方式进一步压榨：
立即学习“Python免费学习笔记（深入）”；
python-flask-vue-creator
下载
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
-
用短而固定的键名：
{str(i): ...}比{f"user_{i}_profile": ...}节省约 30% 键存储开销（实测 10 万条时差 8MB+） -
避免动态增长：如果知道最终大小，用
dict.fromkeys(keys, default)预分配，比逐个dict[key] = val减少哈希冲突导致的空位浪费 -
考虑替代结构：若键是连续整数，用
list或array.array('i')；若只查不改，用frozendict（第三方）或types.MappingProxyType可略微降低运行时开销
clear() 后字典真的更小？是的，但别依赖它
调用 d.clear() 后，sys.getsizeof(d) 会从约 240 字节降到 72 字节，因为底层 keytable 被重置为静态空表 Py_EMPTY_KEYS。但这只是“视觉上”变小——一旦你再插入新项，它立刻按需扩容，内存又涨回去。
容易踩的坑：
- 把
clear()当成内存释放手段，结果发现 RSS（常驻集）没降——因为 Python 不会把内存还给系统，只留着复用 - 反复
clear()+update()大量数据，不如直接新建字典：d = {k: v for ...}，避免旧哈希表残留碎片
什么时候该放弃 dict？
当你的“字典”实际是固定 schema 的记录集合（比如 10 万用户信息），继续用 dict 就是浪费：
- 每个
dict实例自带约 240 字节基础开销，10 万条就是额外 24MB - 键字符串重复存储（每个
'user_id'都存一遍），不如用__slots__类 +array或struct打包 - 推荐路径：先用
pandas.DataFrame（memory_usage(deep=True)查真实占用），再根据列类型选numpy.ndarray或pyarrow.Table
最易被忽略的一点：字典内存优化永远要配合数据生命周期看——缓存一个永不淘汰的巨型字典，再怎么压也白搭。
