Python 3.11 字典操作更快，因哈希表桶定位改用掩码运算替代取模，且 setdefault 字节码路径优化；无需改代码，升级即生效，兼容性不变。
Python 3.11 的字典操作变快，不是靠改 dict 接口或加新方法，而是解释器底层对哈希表的访问路径做了特化——尤其是键查找和插入时的指令跳转更少、缓存局部性更好。你不用改一行代码，只要升级到 3.11 就能拿到收益。
哈希表桶定位从取模变成掩码运算
Python 字典内部用数组（“桶”）存储键值对，老版本用 hash(key) % table_size 算下标，除法指令开销大且难预测；3.11 要求桶数组长度始终是 2 的幂，于是把取模换成位运算 hash(key) & (table_size - 1)，单条 CPU 指令搞定，分支预测更稳。
这要求扩容逻辑必须严格维持 2 的幂大小，而 3.11 确实强化了该约束——哪怕你手动调用 dict.__resize__（不推荐），解释器也会拦截并重排。
- 影响场景：高频
d[key]、key in d、d[key] = val - 兼容性无问题：所有合法 dict 行为不变，只是底层更快
- 注意点：如果你用 C 扩展直接读写
PyDictObject结构体字段，需检查是否硬编码了取模逻辑
setdefault 和 get 的字节码路径被合并优化
setdefault 在 3.10 中仍会先查一次键是否存在，再决定是否赋值；3.11 把这个判断+赋值流程编译成一条紧凑字节码路径，避免重复哈希计算和桶探测。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
对比效果明显：在循环中反复调用 d.setdefault(k, []) 构建嵌套结构时，3.11 平均比 3.10 快 18%～22%，尤其当字典已较大、冲突概率升高时，优势更突出。
- 真实瓶颈不在 Python 层 if 判断，而在哈希表探查次数
-
get没有写入动作，所以没做同等深度优化，但其底层哈希定位部分同样受益于掩码运算 - 别误以为
setdefault总是比if key not in d: d[key] = default快——后者在极小字典（
扩容阈值与懒删除策略微调
字典扩容触发条件仍是“已用槽位 ≥ 2/3 总槽位”，但 3.11 调整了扩容后新表的初始大小计算方式：不再简单翻倍，而是根据当前负载和历史增长趋势，选择更贴近实际需求的 2 的幂值，减少后续频繁 resize。
同时，删除键后留下的“伪删除”标记（DKIX_DUMMY）现在会被更积极地复用——新插入键若哈希落在该位置，无需再探测下一个空位，直接覆盖，降低平均探测长度。
- 影响最明显的是“增删混合”密集场景，比如缓存淘汰（LRU）、实时指标聚合
- 预分配大字典依然有效：
{k: None for k in keys}比逐个update快，因为绕过了多次阈值检查 - 别依赖
sys.getsizeof(d)推算内存使用——3.11 内部结构微调后，该值可能略低于 3.10，但不代表真实占用变少
真正容易被忽略的点是：这些优化全部发生在 CPython 解释器的 dictobject.c 和字节码执行引擎中，对用户完全透明。你不需要理解掩码运算或探测序列，但得知道——一旦你把脚本从 3.10 升级到 3.11，所有基于 dict 的逻辑都会悄悄变快，尤其是那些以前被诊断为“卡在字典查找”的热路径。
