Python字典与集合底层原理：哈希表、性能对比与工程实践

先问个问题：如果你手里有一份一万个用户的名单，要在里面快速判断某个人是不是会员，你会选列表还是集合？我常拿这个问题考新同事，十有八九第一反应是列表。等程序真的跑在几百万行日志上，就会发现自己写的那个if user_id in user_list慢到了什么程度。列表成员检测是O(n)，集合是O(1)，数据量小的时候无感，一旦过万、过十万，那就是毫秒和秒的差距。

Python的字典（dict）和集合（set）都建立在哈希表之上，底层同源，但用法各有侧重。字典擅长键值映射与关联数据管理，集合则天生适合去重和关系运算。我写了几年Python，越来越觉得这两样东西不是简单的“装数据的容器”，而是解决数据管理问题的高效武器。这篇文章会从哈希底层讲起，用实际场景拆解集合的高阶用法、字典的工程化技巧和不常见的避坑点。不管你是刚入门还是写了两三年Python，应该都能从中找到有价值的东西。

1. 为什么字典快得离谱？扒一扒哈希表的底层

1.1 哈希函数：把任意数据映射到一块抽屉格

字典和集合之所以快，核心是哈希表。哈希表本质上是一个数组，数组的每个槽位对应一个“抽屉”。当你往字典里放一个键值对时，Python不会像列表那样按照位置顺序去找空位，而是先对键做一次哈希计算，得到一个整数，这个整数再经过一次位运算映射到数组的某个下标，然后直接把你这个键值对放到那个槽位上。

python复制>>> hash("python")
1162660189973646744
>>> hash(42)
42
>>> hash((1, 2))
3713081631934410656

细心的你可能会发现，"python"的哈希值在不同的Python进程里可能不一样。这是因为字符串哈希默认加了随机盐（PYTHONHASHSEED），防止恶意构造大量哈希相同的字符串来攻击程序。这个细节在正常业务里很少感知到，但如果你的程序依赖字符串哈希的固定值，就需要注意了。

哈希函数的性质可以类比图书馆的索书号：你不需要一本一本翻书，拿到索书号就能直接走到对应的书架格子。列表查找相当于在一个大储物间里挨个找，而字典是每次根据名字计算出储物格编号，一步到位。

1.2 冲突处理与负载因子：字典扩容的幕后逻辑

哈希表再精妙也有一个绕不开的问题：哈希冲突。两个不同的键可能计算出同样的槽位下标，这是无法避免的，毕竟哈希值是有限范围内的整数，而键可以有无限多种。Python采用开放寻址法的变种来处理冲突：当发现槽位被占用时，会按照一定的探测序列去查找下一个空位，直到找到一个空槽。

这里有个关键数字：负载因子。哈希表不是等满了才扩容，而是当已使用的槽位达到总容量的大约三分之二时，就会触发扩容，把内部数组扩大到原来的数倍，并且把所有已有元素重新计算哈希（rehash）放到新的位置。扩容是耗时操作，但由于均摊到每次插入操作上，字典整体的插入和查找复杂度依然是O(1)。

负载因子带来的启示是：字典是一个典型“空间换时间”的数据结构。它比列表占用更多内存，因为内部数组要保持一定空闲比例来减少冲突。很多人问我为什么程序内存占用比预想高，排查到最后往往是有几个大字典在内存里长期占着。这个代价换来的是一流的随机访问性能，在业务场景里几乎必然值得。

2. 集合不只是去重工具，它是一套完整的关系运算

2.1 四种集合运算：把数学公式直接写进代码

很多教程提到集合只会说“集合可以用来去重”，这其实是低估了它。集合真正的强势在于关系运算：交集、并集、差集、对称差集，正好对应数据处理中最常见的几类问题。

来看一个例子。电商运营经常要分析“哪些用户既是会员又在本月下过单”，新手可能会写两层循环，老手直接用集合交集：

python复制vip_users = {"alice", "bob", "carol", "dave"}
month_order_users = {"bob", "dave", "eve", "frank"}

# 交集：既是会员又下过单
print(vip_users & month_order_users)      # {'bob', 'dave'}

# 并集：所有用户
print(vip_users | month_order_users)      # {'alice', 'bob', 'carol', 'dave', 'eve', 'frank'}

# 差集：会员但没下过单
print(vip_users - month_order_users)      # {'alice', 'carol'}

# 对称差集：只出现在其中一个集合里的用户
print(vip_users ^ month_order_users)      # {'alice', 'carol', 'eve', 'frank'}

运算符和方法都可以完成这些操作，区别在于：

我个人建议代码里用带方法名的写法，比如a.intersection(b)，因为可读性更强，别人一眼就能看出意图。运算符写法适合在交互式环境里快速验证。

还有两个判断方法经常被忽略：issubset和issuperset。比如要检查一个权限集合是否包含另一个权限集合的所有元素，直接required_perm <= user_perm就能判断，比逐个遍历优雅得多。

2.2 集合推导式与条件过滤的配合

集合推导式和列表推导式语法很像，只是把方括号换成花括号：

python复制# 从一段文本中提取所有唯一单词，并过滤掉长度小于等于3的
text = "python set dict hash table is fast and useful"
words = {word for word in text.split() if len(word) > 3}
# {'dict', 'fast', 'hash', 'python', 'set', 'table', 'useful'}

再比如，你有一份订单数据，想快速知道哪些品类被购买过，一个集合推导式就够了：

python复制orders = [
    {"category": "家电", "user": "u1001"},
    {"category": "数码", "user": "u1002"},
    {"category": "家电", "user": "u1003"},
]
categories = {order["category"] for order in orders}
# {'家电', '数码'}

集合推导式的执行效率和列表推导式几乎一致，但带了自动去重，省掉一行set()包裹。

2.3 成员检测性能对比：什么时候该用集合

前面提到集合的in是O(1)，而列表的in是O(n)。对于小数据可能不明显，但量级上来了差距极其恐怖。我简单做过测试，在一百万个元素里判断某个值是否存在，列表要做几十万次比较，耗时几十毫秒甚至上百毫秒，集合几乎每次都在微秒级别。

但这不是说所有场景都应该用集合。有几种情况不建议用：

• 你需要保持元素的插入顺序。集合是无序的（严格说是不保证顺序），如果顺序重要，应该用列表或dict来辅助。
• 元素需要重复。集合天生去重，没法存重复值。
• 内存极度紧张。集合的哈希表结构比列表占用更多内存，小列表存几十个元素没必要换成集合。

我的经验是：数据量超过一千、查找操作频繁时，可以无脑换集合。数据量小且需要顺序，就继续用列表。

3. 字典的工程化技巧：get、setdefault、defaultdict与推导式

3.1 从传统循环到字典推导式的进化

字典推导式是构建字典最紧凑的方式，它做的事情和循环一样，但代码可读性高一个档次：

python复制# 传统写法
user_id_map = {}
for user in users:
    user_id_map[user["name"]] = user["id"]

# 推导式写法
user_id_map = {user["name"]: user["id"] for user in users}

几个常用套路值得记下来：

python复制# 词频统计（配合Counter更简洁，但面试或手写时常用这个）
word_count = {word: text.split().count(word) for word in set(text.split())}

# 从两个列表构建字典
names = ["alice", "bob", "carol"]
ages = [25, 30, 35]
name_age = dict(zip(names, ages))

# 带条件的字典推导式
filtered = {k: v for k, v in raw.items() if v is not None}

用推导式还有一个额外好处：它天然产生一个新的字典对象，不会意外修改源字典。

3.2 防御式取值：get与setdefault的适用边界

这两个方法我几乎每天都在用，但它们的定位完全不同。

get(key, default)用于“取不到值时给个默认值”：

python复制score = scores.get(user_id, 0)  # 没有这个用户就当0分处理

setdefault(key, default)则更进一步：如果key不存在，就把这个默认值写进字典，然后再返回。典型场景是构建“键 -> 列表/集合/字典”的多层结构：

python复制# 需求：把商品按品类分组
categorized = {}
for product in products:
    categorized.setdefault(product["category"], []).append(product)

这样做的好处是不用手动判断key是否存在。但我必须提醒一个容易踩的坑：setdefault的默认值参数是即刻构造的，不会因为key存在就不创建。比如：

python复制categorized.setdefault(category, [])  # 这里[]每次都会创建一个新列表，即使key已经存在

如果默认值构造代价很高，这种写法会浪费资源。更稳妥的方案是用下面的defaultdict，它能在真正需要时才调用工厂函数。

3.3 defaultdict与Counter：处理“键不存在”的终极方案

collections.defaultdict是字典的强化版，你只需要在创建时指定一个工厂函数，之后访问不存在key时它会自动调用工厂函数生成默认值并写入：

python复制from collections import defaultdict

# 默认值为整数0，适合计数
counter = defaultdict(int)

# 默认值为空列表，适合分组
groups = defaultdict(list)

# 默认值为空集合，适合去重收集
user_sets = defaultdict(set)

用defaultdict改写分组逻辑：

python复制categorized = defaultdict(list)
for product in products:
    categorized[product["category"]].append(product)

清晰、快速、没有多余的判断。和setdefault相比，defaultdict的默认值是惰性的，而且可读性更强。

Counter则是专门为计数而生的工具。比如统计订单中最热门的品类：

python复制from collections import Counter

category_counter = Counter(order["category"] for order in orders)
print(category_counter.most_common(3))
# [('家电', 120), ('数码', 98), ('食品', 75)]

Counter还支持加减运算、交集并集操作，比如合并两个时段的订单统计：counter1 + counter2。这在做环比、同比统计时非常方便。

3.4 视图对象与合并操作：动态追踪而不复制

字典的keys()、values()、items()返回的是视图对象，不是列表。视图的最大特点是对字典内容的动态反映：

python复制d = {"a": 1, "b": 2}
keys_view = d.keys()
print(list(keys_view))  # ['a', 'b']

d["c"] = 3
print(list(keys_view))  # ['a', 'b', 'c']，视图自动更新

理解这一点有助于避免内存浪费。有些人习惯写list(d.keys())来做快照，这没错，但要意识到快照是复制的；如果只需要遍历一次，直接用视图即可。

Python 3.9之后字典支持了|合并运算符：

python复制base_config = {"host": "localhost", "port": 8080}
override_config = {"port": 9090, "debug": True}
merged = base_config | override_config
# {'host': 'localhost', 'port': 9090, 'debug': True}

注意后面的字典会覆盖前面的重复键。如果你用的是3.9以前的版本，可以用{**base_config, **override_config}达到相同效果。这两个写法我都建议直接背下来，工作中非常常用。

4. 实战案例：用字典和集合构建用户标签分析系统

4.1 需求与数据模型设计

假设运营同学周末发来一个需求：他们想知道“购买过家电的用户里，有多少人也买过数码”，还要按省份看每个品类的GMV（成交总额）排名。这类分析如果直接去SQL里跑，也能做，但用Python原生的字典和集合处理，代码短、逻辑透明，特别适合数据量在几十万条以内的快速分析场景。

我先构造一批订单数据，字段分别是用户ID、品类、金额、省份：

python复制import random
from collections import defaultdict, Counter

random.seed(42)
users = [f"u{i:04d}" for i in range(1, 201)]
categories = ["家电", "数码", "美妆", "食品", "服饰"]
provinces = ["广东", "北京", "上海", "浙江", "四川"]

orders = []
for _ in range(3000):
    orders.append((
        random.choice(users),        # 用户ID
        random.choice(categories),   # 品类
        random.randint(50, 10000),   # 金额
        random.choice(provinces),    # 省份
    ))

4.2 集合运算实现人群重合度分析

先把每个品类覆盖的用户集合构建出来，然后用集合运算计算人群重叠：

python复制# 每个品类下有哪些用户
category_users = defaultdict(set)

for uid, cat, amount, prov in orders:
    category_users[cat].add(uid)

home_appliances = category_users["家电"]
digital = category_users["数码"]

overlap = home_appliances & digital
all_buyers = home_appliances | digital

print("家电品类用户数:", len(home_appliances))
print("数码品类用户数:", len(digital))
print("两个品类都购买过的用户数:", len(overlap))
print("两个品类总覆盖用户数:", len(all_buyers))
print("重叠比例(相对并集): {:.2%}".format(len(overlap) / len(all_buyers)))

输出结果类似这样：

code复制家电品类用户数: 158
数码品类用户数: 162
两个品类都购买过的用户数: 54
两个品类总覆盖用户数: 266
重叠比例(相对并集): 20.30%

运营看到“有54个用户同时买了家电和数码”这个数字，就能直接判断是不是要针对这批人群做跨品类营销。整个计算过程不需要任何第三方库，纯Python数据结构就把事情干完了。

4.3 字典嵌套实现多维度统计

接下来按省份分析品类偏好。这里我用defaultdict(Counter)构建一个两层结构：第一层是省份，第二层是品类计数器。

python复制province_category = defaultdict(Counter)

for uid, cat, amount, prov in orders:
    province_category[prov][cat] += 1

for prov, counter in province_category.items():
    top_category, count = counter.most_common(1)[0]
    print(f"{prov} 最热门品类: {top_category}，订单数: {count}")

再按省份统计各品类的GMV，这时需要用到嵌套默认字典：

python复制# key是(省份, 品类)，value是总金额
province_cat_gmv = defaultdict(int)
for uid, cat, amount, prov in orders:
    province_cat_gmv[(prov, cat)] += amount

for (prov, cat), gmv in sorted(province_cat_gmv.items(), key=lambda x: x[1], reverse=True)[:5]:
    print(f"{prov} - {cat}: {gmv}")

这里有个小技巧：用元组(省份, 品类)作为字典的key，天然表达“组合键”语义，比自己再套一层字典更简洁。元组是支持哈希的，只要内部元素都是不可变对象，就可以放心当key。这种组合键的用法在生产环境很常见。

经过这些计算，运营需要的报表几分钟就能跑出来。相比SQL，用字典和集合写分析代码还有一个优势：每一步都可以print出来查看中间结果，数据逻辑出现问题时更容易定位。

5. 踩坑实录：可变Key、遍历修改与自定义哈希

5.1 “列表能不能当字典Key”：哈希性和可变性的冲突

几乎所有Python开发者都会遇到这个错误：

python复制d = {}
d[[1, 2]] = "test"
# TypeError: unhashable type: 'list'

新手可能会觉得奇怪：列表不也是对象吗，为什么不能当key？根本原因在于哈希表的约束：作为key的对象必须是可哈希的，而且哈希值在对象生命周期内不能变化。列表是可变的，如果列表能当key，你把列表修改了，它对应的哈希值就变了，之前存储的位置就找不到了，整个字典就崩了。

解决方案也很简单：先把可变对象转成不可变形式，最常见的是转元组或字符串：

python复制d[tuple([1, 2])] = "test"
d[tuple(sorted([3, 1, 2]))] = "sorted"

需要提醒的是，元组里如果包含可变对象，同样不可哈希：

python复制>>> hash((1, [2]))
TypeError: unhashable type: 'list'

所以“元组一定是可哈希的”这个说法并不准确，必须是“元组及其内部所有元素都不可变”才行。

5.2 遍历字典时删改元素：RuntimeError的根源

看一段很常见的错误代码：

python复制d = {"a": 1, "b": 2, "c": 3}
for k in d:
    if k == "b":
        del d[k]
# RuntimeError: dictionary changed size during iteration

为什么Python不允许在遍历字典时删除元素？因为字典的迭代器依赖内部结构的当前状态，如果你删掉一个元素，迭代器的位置就不可靠了，继续遍历可能跳过元素或重复元素。这是为了保护数据一致性而做的限制。

解决办法有几种：

python复制# 方法一：先拿到键的列表快照
for k in list(d.keys()):
    if k == "b":
        del d[k]

# 方法二：用字典推导式过滤生成新字典（推荐）
d = {k: v for k, v in d.items() if k != "b"}

方法二更推荐，因为它是纯函数式的写法，不修改原字典，逻辑清晰，而且性能也不错。

5.3 自定义对象的哈希策略

当你在自定义类中重写__eq__方法时，Python有一个隐含规定：如果两个对象相等，它们的哈希值必须相等。拿点坐标类举例：

python复制class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __eq__(self, other):
        return isinstance(other, Point) and self.x == other.x and self.y == other.y

    def __hash__(self):
        return hash((self.x, self.y))

如果只重写__eq__而不重写__hash__，Python会把该类的__hash__设置为None，此时这个类的实例就不能放进集合或作为字典key了：

python复制p1 = Point(1, 2)
p2 = Point(1, 2)
s = {p1, p2}
print(len(s))  # 如果只重写eq，这里会报TypeError

重写__hash__的通用做法是：把对象里参与相等性判断的所有不可变字段打包成元组，然后调用hash()。这个方案简单可靠，我一直在用。

另外要特别小心：如果对象是可变的，最好不要给它实现__hash__，或者确保相等的两个对象在哈希计算时不依赖会变化的字段，否则会制造出“能放进去但取不出来”的幽灵数据。

5.4 容易被忽略的细节

第一个是可变默认参数。def add_user(user, cache={})这种写法非常危险，因为默认字典在函数定义时只创建一次，所有调用共享同一个字典。正确做法是：

python复制def add_user(user, cache=None):
    if cache is None:
        cache = {}
    cache[user["id"]] = user

第二个是大字典的拷贝问题。copy()是浅拷贝，嵌套的列表、字典仍然是共享的。做数据隔离时一定要用copy.deepcopy()，但它开销很大，能少用就少用。

第三个是Python 3.7之前字典不保证插入顺序，如果你还在维护老项目，遇到字典顺序错乱不要惊讶。Python 3.7以后字典按插入顺序排列，这在写配置读取、日志解析时省了很多心。

最后一个和JSON序列化相关。JSON的key必须是字符串，所以如果你要把字典序列化成JSON，务必提前把key转成字符串，避免序列化时抛出TypeError。我在对接第三方接口时踩过这个坑，处理了一晚上数据，结果一序列化全崩了。

我的使用体会

做Python开发越久，越觉得字典和集合是标准库里最值得深入研究的数据结构。凡是需要“按名字找东西”的场景，优先考虑字典；凡是需要“判断某样东西在不在集合里”或者“计算不同集合之间的关系”的场景，优先考虑集合。我在代码评审时只要看到有人在循环里嵌套in判断，都会下意识提醒对方：这里换成集合试试。按这个习惯写了两年，程序的性能问题和隐藏Bug都少了不少。希望这篇文章对你有实际帮助，少走一点我当年绕过的弯路。