Python dict的哈希值由键对象的__hash__方法计算，要求相等对象哈希值相同；冲突时用开放寻址法探测，负载过高会扩容；有序性不影响哈希原理。
Python dict 的哈希值怎么算出来的？
Python 中 dict 的键必须是可哈希的（hashable），核心在于每个键对象必须实现 __hash__ 方法，且该方法返回一个整数。这个整数不是任意的：它得满足「相等对象哈希值必须相同」——比如 "abc" 和 "abc"（字符串字面量）或两个内容相同的 tuple，它们的 hash() 结果一致。
但注意：不同对象可能哈希冲突（即哈希值相同），这是正常现象，Python 不回避，而是靠后续机制处理。内置类型如 str、int、tuple（元素全可哈希）的哈希算法是确定性的，且对相同输入在同一次 Python 进程中结果稳定（不过从 3.3 起默认启用 hash 随机化，跨进程不保证一致，防止 DOS 攻击）。
自定义类若要作 dict 键，必须同时定义 __hash__ 和 __eq__，且逻辑自洽：若 a == b 为真，则 hash(a) == hash(b) 必须为真；反之不成立。
哈希冲突时 dict 怎么找对的 key？
Python 的 dict 底层用的是开放寻址法（open addressing），不是链地址法（chaining）。这意味着每个桶（slot）只存一个键值对，冲突时不拉链，而是按固定探测序列找下一个空位或匹配项。
立即学习“Python免费学习笔记（深入）”；
具体来说：
- 初始位置由
hash(key) & (mask)算出，其中mask = table_size - 1（表长恒为 2 的幂） - 若该位置已被占用，就按探测函数（如
(5*j + 1) | 1）生成新索引，跳着找 - 查找时，只要遇到空槽（
NULL）就停止——说明 key 不存在；若遇到已删除标记（DELETED），继续探；若遇到哈希值匹配且==成立的 key，就命中
这种设计让缓存局部性更好，但要求负载因子（used/size）不能太高，所以 Python 会在使用量达 2/3 左右时自动扩容（rehash）。
为什么有时 dict 查找变慢？和哈希分布有关吗？
是的，哈希分布直接影响探测长度。如果大量键的哈希值集中在少数几个低位上（比如自定义 __hash__ 返回值总为偶数），那它们会挤在连续几个桶里，导致平均查找/插入需要多次探测，性能退化到接近 O(n)。
常见踩坑点：
- 自定义类的
__hash__只返回某个字段的 id() 或地址，而该字段本身哈希质量差 - 用可变对象（如 list）当 key —— 实际上会报
TypeError: unhashable type，但有人误以为“没报错就安全”，其实只是没触发 - 大量短字符串作为 key，又恰好哈希碰撞高（如
"a","b","c"在某些版本中哈希高位几乎一样）
验证方式：用 sys.getsizeof(your_dict) 看实际内存占用，再结合 your_dict.__sizeof__() 和键数量估算负载率；更直接的是看 your_dict.keys().__len__() 和底层表大小比值（需用 CPython 内部结构，一般不建议）。
Python 3.7+ 的 dict 保持插入顺序，会影响哈希原理吗？
不影响哈希计算和冲突处理逻辑。顺序保持是通过额外维护一个「插入序数组」（sparse array of indices）实现的，和哈希表主结构解耦。也就是说：dict 仍按哈希值决定存储位置，但迭代时按另一个数组顺序输出。
这点常被误解——以为“有序”意味着底层改用红黑树或跳表。其实没有，它仍是哈希表，只是多了个元数据层。因此所有关于哈希冲突、扩容、性能退化的分析依然适用。
真正容易被忽略的是：当你把 dict 当作“有序容器”用时，别忘了它的哈希本质——比如用 dict.fromkeys(keys) 去去重并保序，看似简洁，但如果 keys 里有大量哈希冲突项，构造过程可能意外变慢，尤其在初始化阶段。
