Python 3.6+ 字典更省内存是因为采用 Compact Dict 布局，只存储一份键值对数组，散列表仅存索引，分离稀疏哈希表与密集数据，3.11 相比 3.6 再省 5%～8% 内存。
Python 3.6+ 字典为什么更省内存？关键在 Compact Dict 布局
Python 3.6 开始，dict 内部改用 Compact Dict（紧凑字典）布局，3.11 进一步优化了内存对齐和哈希缓存策略。这不是“小修小补”，而是结构级重构：旧版 dict 在内存中存两份数据（散列表 + 键值对数组），新版只存一份键值对数组，散列表只存索引。结果是——同样 10 万个 str→int 映射，3.11 比 3.6 再省约 5%～8% 内存，比 3.5 及以前省近 25%。
这背后没魔法，只是把稀疏的哈希表（大量 NULL 槽位）和密集的键值对分离，再用偏移量代替指针跳转。代价是插入时需多一次间接寻址，但现代 CPU 缓存友好性提升远超这点开销。
怎么实测两个版本的字典内存差异？别信 sys.getsizeof() 直接结果
sys.getsizeof() 返回的是字典对象头 + 散列表内存，但不包含键值对象本身的开销。想对比真实占用，必须统一构造方式、禁用哈希随机化，并测量完整对象图：
- 启动时加
-X hashseed=0或设环境变量PYTHONHASHSEED=0，避免哈希扰动影响桶分布 - 用
__sizeof__()+ 手动递归计算键/值对象（如字符串的__sizeof__()），或用第三方库pympler.asizeof.asizeof() - 构造字典时用
dict(zip(keys, values))而非逐个d[k] = v，避免扩容过程中的临时冗余
示例：10 万长度固定字符串键 + 小整数，在 3.6.15 和 3.11.9 下用 asizeof() 测得总内存分别为 ~12.1 MB 和 ~11.3 MB——差值主要来自散列表缩容与填充率提升（3.11 默认填充阈值从 2/3 提至 3/4）。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
Compact Dict 对迭代顺序和性能的影响不是“顺便优化”，而是设计前提
插入有序（insertion order preservation）不是 3.7 “正式保证”的功能，而是 3.6 Compact Dict 的自然副产品：键值对按插入顺序线性存储，遍历只需顺序读数组。这意味着：
- 任何
for k in d:或list(d.keys())都是 O(n) 时间且 cache-locality 极佳，比老版乱序遍历快 10%～15% - 但
popitem(last=True)在 3.11 比 3.6 略快，因为末尾索引直接可得；而last=False（弹出第一个）仍需扫描，无加速 - 如果依赖“字典天然乱序”做简单混淆（比如某些老测试用例），升级后会失败——这不是 bug，是 layout 改变导致的确定性行为变化
哪些场景下 Compact Dict 的优势会被抵消？注意这几个隐性开销
紧凑布局省空间，但不是万能的。以下情况可能让 3.11 的字典反而“更重”或更慢：
- 键类型是自定义类且未实现
__hash__或__eq__：Compact Dict 仍要存完整对象引用，而旧版可能因哈希冲突多分配空槽，此时内存差异缩小甚至反转 - 频繁删除 + 插入不同键：3.11 对“已删除槽位”的复用逻辑更激进，但若键哈希分布极差（如全碰撞），仍会触发 resize，且新 resize 后的表初始大小可能比 3.6 更大（因最小尺寸从 8 升到 32）
- 使用
dict.fromkeys(iterable, value)创建含大量重复键的字典：3.6 和 3.11 都会去重，但 3.11 的键数组分配更“贪心”，若 iterable 极长（千万级），预分配可能略多
真正要紧的不是绝对内存数字，而是你字典里键值对象本身的生命周期和引用关系——Compact Dict 只管容器结构，不管里面塞的是短字符串还是带循环引用的嵌套 dict。
