戈玄白今天要做题在Python里写代码，几乎没人离得开字典。不管是缓存数据、解析JSON、维护配置，还是算法题里统计频率，dict都是很多场景下的首选。你有没有认真想过，一次 d[key] = value 的背后，Python到底做了什么？为什么字典的查找能如此之快，而有时候内存又大得离谱？这些都指向一个老朋友：哈希表。
这篇内容适合三类人：刚学完Python基础、想真正理解字典和集合底层原理的人；准备面试、需要把“平均O(1)”讲清楚的人；已经写过不少代码、但被可变对象做key、哈希冲突、进程间哈希不一致这类问题折腾过的人。我会结合CPython的源码逻辑、实际测试数据和一些踩坑经历，把哈希表这件事掰开揉碎讲明白。读完你不仅能搞懂dict和set的运行机制，还能写出更稳、更快的代码。
1. 哈希表凭什么让Python的字典查找快到离谱
1.1 一个基础问题：哈希表到底解决了什么痛点
先想一个最普通的场景：一个列表里存了一万个用户名，现在要判断某个用户名是否存在。最直接的办法是for循环遍历，逐个比较，这就是线性查找。运气好时第一个就命中，运气差时得走到最后，平均下来要比较五千次。随着数据量翻倍，比较次数也跟着翻倍，这就是O(n)的含义。
哈希表的思路完全不同。它不靠比较，靠的是“算出位置”。你可以把哈希表想象成一个巨大的储物柜，每个柜子都有编号。我们要存放一个东西时，先拿钥匙（key）算一个数字，再把这个数字映射成柜子编号，直接把东西放进去。取的时候同样用钥匙算一遍编号，直接打开柜子拿走东西。整个过程不依赖你有多少东西，也不依赖目标在柜子里的什么位置。
所以哈希表的核心价值就一句话：把查找问题变成“算位置”问题。在hash函数足够均匀的情况下，查找、插入、删除都能做到平均常数时间。这是链表、数组这些线性结构很难做到的。数组虽然能用下标直接访问，但下标和业务数据往往没有映射关系；链表更是只能从头往后找。哈希表相当于在“业务key”和“存储位置”之间架了一座桥。
1.2 三个核心构件：hash函数、数组、负载因子
哈希表不是只有一个数组那么简单，它的运作依赖三个构件。
第一是hash函数。它的职责是把任意类型的数据（字符串、元组、数字、自定义对象）转成一个固定范围内的整数。注意，这个整数通常很大，不能直接当数组下标用，所以后面还要做一次取模或者位运算，把它压缩到数组容量范围内。
第二是底层的数组。所有键值对最终都存在一个数组里，数组的每个槽位可能是一个键值对，也可能是空的，也可能被标记为“已删除”。hash函数算出的值经过映射后指向数组的某个下标，这就是所谓的“桶”（bucket）。
第三是负载因子。它等于“已存储元素个数 / 数组容量”。负载因子太低，空间浪费严重；太高，冲突概率急剧上升。不同语言的处理方式不同，Python的选择非常保守，而且这个数字直接决定了扩容时机。
这三个构件互相制约。hash函数设计得再好，如果负载因子控制不住，冲突也会把性能拖垮；负载因子控制得再好，如果hash函数把很多key映射到同一个桶，也是白搭。所以理解哈希表，不能只看其中一个环节。
1.3 哈希表在Python里远不止dict一个形态
很多人以为哈希表就是字典，其实Python里到处都是它的影子。
dict：最典型的哈希表实现，保存键值对。set和frozenset：可以理解为“只有键没有值”的哈希表，内部结构和dict高度重合。collections.Counter：一个专做计数的dict子类，底层还是哈希表。collections.defaultdict：在访问不存在的key时自动填充默认值，同样是哈希表。functools.lru_cache：缓存函数运行结果时，底层用dict做记忆存储，key是参数组合，value是返回值。- 对象属性的存储：Python对象的
__dict__就是一个字典，这意味着你访问obj.attr时，本质也是在做一次哈希表查询。
理解这一点，你就能明白为什么Python官方一直在优化dict的底层实现。因为dict的性能几乎决定了整个语言的运行效率。2016年Python 3.6版本里dict的内存布局被重新设计，这个改动直接让所有Python程序都享受到了内存和速度的双重优化，而且当时官方说这是个“实现细节”，结果因为太好用，后续版本直接把它定为语言规范了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 扒开CPython底层：dict的存储设计不只是一个数组
2.1 为什么查询是O(1)平均复杂度
这里我先抛出一个反直觉的结论：哈希表的O(1)是“平均”意义上的，不是“所有情况”都如此。最坏情况下所有key都算到同一个桶，查找就退化成O(n)。虽然工程上这个概率极低，但理解这一点能帮你避免