python 3.6+字典内存下降20%~25%的直接原因是cpython将稀疏的pydictentry数组改为indices（稀疏索引）和entries（紧凑键值对）两个分离数组，消除空槽冗余。
Python 3.6+字典内存下降20%~25%的直接原因
因为CPython把原来每个PyDictEntry槽位里“空着也占位”的稀疏结构，换成了两个分离数组：indices（稀疏索引）和entries（紧凑键值对）。前者只存下标或-1，后者按插入顺序连续存放(hash, key, value)，中间不留空洞。
- 老结构：一个长度为2^i的
PyDictEntry[]数组，80%以上槽位常为NULL，但内存已分配 - 新结构：
indices是int数组（通常4或8字节/项），entries是紧凑块，无冗余间隙 - 典型场景下，相同数据量的字典，3.6+比3.5内存减少约20%~25%，尤其在小字典（
紧凑哈希表不是为“有序”设计的，但有序是必然结果
“保留插入顺序”是紧凑结构的副产品，不是目标。你不能靠它做业务逻辑依赖——直到Python 3.7才写入语言规范；3.6只是CPython实现的巧合。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
-
for k in d:快，是因为遍历entries数组即可，不用跳过大量NULL -
popitem(last=False)变慢（O(n)），因为要从头扫描entries找第一个非空项，而last=True仍是O(1) - 如果手动用
dict.fromkeys()构造，仍按插入序；但用{**d1, **d2}合并时，顺序由右操作数决定，不是稳定叠加
Key-Sharing机制进一步压低小字典内存开销
当多个字典键完全相同且全为字符串时，CPython 3.6+会复用同一份键结构（ma_keys），避免重复分配和哈希计算。
- 生效条件苛刻：键必须全为
str、集合完全一致、顺序可不同（因底层只比键名集合） - 不适用于含
int、tuple等非字符串键，也不跨解释器（PyPy无此优化） - 无法主动触发或禁用，是纯运行时判断；大量配置字典（如
{'host': ..., 'port': ...}）受益最明显
扩容行为没变，但每次扩容代价更高
负载因子≥2/3仍触发扩容，但紧凑结构让重哈希更重：不仅要重算所有键的哈希并填indices，还要重排整个entries数组。
- 单次扩容仍是O(n)，但n现在包含更多元数据（hash缓存、索引映射），实际耗时略高于3.5
- 预分配大容量字典（如
dict.fromkeys(range(10000))）不会跳过扩容逻辑，CPython不提供reserve接口 - 高频增删场景下，
del d[k]后留下的DUMMY标记会污染indices，积累到一定比例也会触发“伪扩容”（rehash清理）
indices数组里那些-1和数字混排的细节，才是理解内存节省的关键入口。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
