写了这么多年代码Python里用的最多的数据结构不是列表排第一的肯定是字典排第二的可能就是集合了。这两兄弟表面上一个管映射、一个管去重看起来各干各的但底子里都靠同一套散列表机制吃饭。这篇博文想做的就是把这俩结构从入门到进阶的完整脉络梳理一遍——基础操作怎么用顺手、底层哈希到底怎么回事、什么时候用字典什么时候用集合、遇到性能瓶颈怎么排查一次性说清楚。适合刚学完基础语法、想深入理解开发中高频数据结构的读者也适合准备面试、对源码实现有点好奇的人。1. 为什么Python开发者离不开Dict和Set1.1 散列表Dict和Set共同的底层基石开始写代码之前先花点时间搞清楚一个底层问题字典和集合凭什么能比列表“更快”列表查找一个元素哪怕写的是if item in my_list背后实际上是线性扫描逐个比对。扫描到第几个才找到平均就要花多少时间。一万个元素查一次平均比较五千次一百万个元素平均比较五十万次。数据量一上去性能肉眼可见地变差。字典和集合就完全不是这个路数了。它们底层是一张哈希表存的不是“元素本身”而是“元素的哈希值”加上元素本身。你可以把哈希函数理解成一个计算器——不管输入是字符串、数字还是元组都能稳定算出一个整数这个整数直接用作存储位置的索引。查找的时候算一下目标元素的哈希值直接跳到对应的“格子”里看完全不需要跟其他元素比较。生活里最容易理解哈希表的例子就是图书馆的索引柜每一本书都有一个索书号按索书号直接走到对应书架那一排而不是从第一排开始逐本翻。哈希函数的“幂等性”同一个输入永远得到同一个输出保证了查找步骤的可重复性这是散列表高效的核心前提。Python官方对字典的时间复杂度描述是平均 O(1)——这个“平均”两个字别忽略因为哈希冲突不同元素算出来同一个槽位存在极端情况下会退化成 O(n)。但工程实践中CPython 在冲突处理、扩容策略上做得很稳实际运行基本都稳定在常数时间级别。1.2 Dict和Set各自擅长解决什么类型的问题搞清楚了底层机制就能理解为什么Python社区有句老话“如果你在用列表做查找或去重先停下来想想是不是应该用集合或字典。”Dict是键值映射问题的天然解法。凡是“根据一个标识取另一个值”的场景都属于它的射程范围用户ID映射到用户信息、商品编码映射到库存数量、省份名称映射到省会城市、文件路径映射到文件大小……不用字典你会被迫写一堆并列的列表然后做索引对齐代码丑陋且一改就崩。user_names [张三, 李四, 王五] user_scores [88, 92, 76] # 用字典才是正常人写代码的方式 user_info { 张三: 88, 李四: 92, 王五: 76 }Set是成员判断和去重的利器。判断“这个元素在不在集合里”、对列表去重、计算交集并集差集这些需求用集合一行就能解决。尤其要注意的是Set适合的场景核心在“快查”和“去重”它不保证顺序Python 3.7之后dict保序set依然是无序的它的元素必须是可哈希的hashable这两条限制决定了它的适用边界。我个人的经验是写任何代码之前先问自己一个问题这个需求核心是在做什么如果是“根据A找B”默认首选字典如果是“某个值存在与否”或者“去掉重复项”默认首选集合。这种条件反射式的选型习惯比记住一大堆API更有价值。2. 从零上手Dict的创建、操作与遍历细节很多教程把Dict的知识点列成一个长长的API清单看完了也不知道什么时候该用哪个。我建议换个思路从“怎么建、怎么取、怎么改、怎么遍历”四个动作来理解每个动作记住几个最关键的姿势就够用。2.1 创建字典的几个姿势以及get与[]的差异创建字典至少有五种写法实际开发中最常用的是前两种# 方式一字面量最常用最直观 user {name: 张三, age: 28} # 方式二dict()构造函数配合关键字参数 user dict(name张三, age28) # 方式三从键值对序列创建 pairs [(name, 张三), (age, 28)] user dict(pairs) # 方式四zip两个列表生成 names [张三, 李四] ages [28, 25] user dict(zip(names, ages)) # {张三: 28, 李四: 25} # 方式五fromkeys批量创建通常配合统一初始值 cities [北京, 上海, 广州] visit_count dict.fromkeys(cities, 0) # {北京: 0, 上海: 0, 广州: 0}这几种方式里最容易踩坑的是fromkeys它的第二个参数如果填的是一个可变对象比如空列表所有键会共享同一个列表对象改一个全部跟着变。这是一个非常经典的坑后面章节会展开讲。取值的时候新手最常见的选择困难是用dict[key]还是dict.get(key)它们的行为差异在于键不存在时的处理中括号写法直接抛KeyError而get方法返回None或指定的默认值。日常业务里“取不到就拉倒”的情况非常多用get能把三行防御代码压缩成一行# 中括号写法取不安全 # try: # email user[email] # except KeyError: # email 未设置 # get写法一行搞定 email user.get(email, 未设置)但这不代表中括号写法没用。当你确定键必须存在的时候中括号写法更有助于提前暴露数据问题——取不到就立刻报错而不是带着None继续跑最后在某个莫名其妙的角落才炸。收集日志、解析配置这类场景我反而推荐中括号写法让异常尽早暴露。2.2 遍历的三种姿势items、keys、values各怎么选遍历字典看起来很简单但有三个细节值得说。第一个细节绝大多数时候应该直接用for key, value in dict.items()同时拿到键和值。需要用键去取值的场景里有人会写成for key in dict:然后在循环体里再执行一次dict[key]——这相当于每一次循环多做一次哈希查找。数据量小无所谓但习惯一旦养成了处理大字典时性能差距会很明显。# 推荐直接解包 for key, value in user_info.items(): print(f{key}: {value}) # 不推荐每轮循环额外做一次查找 for key in user_info: print(f{key}: {user_info[key]})第二个细节只遍历键用keys()只遍历值用values()都不要转换成列表再遍历。在Python 3中dict.keys()返回的是视图view对象而不是列表它动态同步字典内容而且不占额外内存。很多人为了“保险”写list(dict.keys())其实是多此一举。第三个细节也是个大坑遍历字典的过程中不要直接修改字典——新增键、删除键都别干。下面的代码在某些时候能跑通但结果完全取决于当前字典的内部存储状态属于典型的未定义风险my_dict {a: 1, b: 2, c: 3} for key in my_dict: if key b: del my_dict[key] # 运行时可能直接抛RuntimeError正确做法是把要删的键先收集到列表遍历完成之后再统一删to_delete [key for key in my_dict if my_dict[key] 2] for key in to_delete: del my_dict[key]2.3 修改、合并与解包的高效写法单键修改就没啥好说的dict[key] value即可。批量更新和合并有三个实用姿势# update合并把另一个字典或键值对序列合并进来 base {name: 张三, age: 28} base.update({age: 29, city: 上海}) # 覆盖式合并 # Python 3.9的管道操作符 a {x: 1, y: 2} b {y: 3, z: 4} merged a | b # {x: 1, y: 3, z: 4}注意右边的值覆盖左边 # 双星号解包合并旧版本也能用 merged {**a, **b}update是原地修改|和**解包是生成新字典。在函数里写参数的时候**kwargs接收的关键字参数本质上就是一个字典能把外部传入的配置一层层合并覆盖这种写法在配置管理中非常常见。2.4 pop、popitem、del删除键值对时的三种选择和坑删除操作里del dict[key]、dict.pop(key, default)、dict.popitem()各有各的适用场景。del简单粗暴但键不存在时抛KeyError需要自己保证键一定存在或者包一层异常处理。pop(key, default)更实用——删除的同时能拿到值还能指定键不存在时的返回值相当于“取走并移除”item cart.pop(锤子, None) if item is not None: print(移除成功) else: print(购物车里没有锤子不需要处理)popitem()删除并返回末尾的键值对在Python 3.7中由于字典保序“末尾”就是最后插入的那一项。这个特性经常被用来实现简单的LRU风格淘汰策略缓冲区满了就popitem()丢的总是最老插入的数据。注意popitem()在空字典上会抛KeyError调用之前最好判断一下。3. Set的完整操作指南与隐藏能力3.1 创建集合的两种方式以及add/remove/discard的区别集合的创建很简单但有一个语法细节新手必踩{}创建的是空字典不是空集合。想创建空集合必须用set()。a {} # 空字典 b set() # 空集合 c {1, 2, 3} # 非空集合用花括号add、remove、discard三个方法的分工很清晰add添加元素元素已存在时什么都不发生也不报错remove删除元素元素不存在时抛KeyErrordiscard删除元素元素不存在时什么都不发生。写代码时怎么选我的习惯是需要明确感知到“元素不存在”这个异常情况时用remove让程序尽早暴露问题只是“尽可能删掉删不掉就算”的时候用discard。tasks {爬虫任务1, 爬虫任务2, 数据清洗} # 任务完成后清理 tasks.discard(爬虫任务1) # 不存在也不报错适合幂等操作 tasks.remove(不存在任务) # 抛KeyError适合严格预期存在的场景还有个容易被忽略的细节集合的元素必须是可哈希的。列表、字典这类可变对象不能放进集合如果业务需要放一组数据进去要么转成元组要么转成不可变的frozenset。这个限制源自集合内部依赖哈希表存储可变对象一旦存放后内容变了哈希值和存储位置的对应关系就乱了整个结构都崩了。同样的逻辑也适用于字典的键。3.2 集合运算交集、并集、差集、对称差的实战运用集合真正的“杀手锏”在于内建的集合运算。列表做这些事需要写循环加条件集合直接一行a {1, 2, 3, 4} b {3, 4, 5, 6} a b # 交集{3, 4} a | b # 并集{1, 2, 3, 4, 5, 6} a - b # 差集{1, 2} a ^ b # 对称差{1, 2, 5, 6}这几个运算在数据分析场景极其常用。举个具体的例子假设有两份用户名单一份是“注册用户”一份是“已下单用户”判断“注册了但从未下单的用户”就是差集运算registered {u1001, u1002, u1003, u1004} ordered {u1001, u1005} # 潜力用户注册了但没下过单 potential registered - ordered print(potential) # {u1003, u1002, u1004}还有子集判断方法issubset和issuperset在处理权限、配置继承关系时很好用。比如判断“用户拥有的权限集合”是否覆盖了“该功能要求的权限集合”其实就是一次superset判断required {读, 写} user_permissions {读, 写, 执行} can_execute required.issubset(user_permissions) # True3.3 frozenset需要作为字典键或集合元素时的最佳选择你可能已经注意到集合不能放进集合列表也不能作为字典的键。那如果业务上就是需要把一组数据作为整体去判断唯一性呢答案是frozenset——不可变集合。# 每组会话包含一批IP地址要按这批IP去重 session_ips frozenset({192.168.1.1, 10.0.0.2, 172.16.0.8}) unique_sessions {session_ips: session_001} print(unique_sessions[frozenset({10.0.0.2, 192.168.1.1, 172.16.0.8})]) # 输出 session_001因为frozenset是可哈希的内容相同就能找到注意frozenset里的元素本身也必须是可哈希的这个限制传递下去了。实际开发中对“一组标签”“一组权限码”“一组IP”做缓存键或去重依据时frozenset是比“排序后转字符串”更优雅的解法。4. 进阶实战推导式、标准库组合与性能优化基础操作熟悉之后真正让开发效率起飞的是几个进阶手段。这一章会结合真实场景讲讲字典推导式、defaultdict、Counter以及性能优化方向。4.1 字典推导式与集合推导式一行代码完成建表与筛选推导式是Python非常优雅的语法特性。字典推导式可以从任何可迭代对象快速生成字典还能带上过滤条件# 从商品列表生成“名称-价格”字典价格必须大于0 products [ {name: 手机, price: 3999}, {name: 耳机, price: 499}, {name: 赠品, price: 0}, ] price_map {p[name]: p[price] for p in products if p[price] 0}集合推导式则在去重、筛选场景里非常好用# 提取所有评论中的表情关键词去重后 comments [太赞了, 一般吧, 太赞了, 还有待提升, 一般吧] unique_words {word for word in comments if len(word) 3} # 结果{太赞了, 一般吧}字典推导式背后的逻辑其实就是在迭代过程中执行“键值对生成 条件过滤”它跟下面的传统写法完全等价但可读性和执行效率都更好result {} for item in iterable: if condition(item): result[transform_key(item)] transform_value(item)唯一要注意的是别为了炫技写太复杂的推导式——超过两层的嵌套推导式可读性急剧下降。我的建议是逻辑简单的用推导式一行搞定逻辑复杂的老老实实写循环代码首先是给维护者看的包括三个月后的自己。4.2 defaultdict与Counter带默认值的字典和词频统计利器普通字典访问不存在的键会抛KeyError这在编写“统计次数”这类累加逻辑时非常别扭words [apple, banana, apple, orange, banana, apple] counts {} for word in words: if word not in counts: counts[word] 0 counts[word] 1collections.defaultdict能完美解决这类“访问不存在键时提供默认值”的需求。构造时传入一个工厂函数键不存在时会自动调用它生成默认值from collections import defaultdict counts defaultdict(int) for word in words: counts[word] 1 # 无需判断不存在时默认从0开始 print(counts) # defaultdict(class int, {apple: 3, banana: 2, orange: 1})defaultdict(list)在构建“分组”结构时更是常用。比如把订单按城市分组orders [ (上海, 订单A), (北京, 订单B), (上海, 订单C), ] city_orders defaultdict(list) for city, order in orders: city_orders[city].append(order) print(city_orders) # defaultdict(class list, {上海: [订单A, 订单C], 北京: [订单B]})Counter更是直接为“计数”量身定做它是字典的子类内部已经把累计逻辑封装好了还能直接取 TopNfrom collections import Counter counts Counter(words) print(counts.most_common(2)) # [(apple, 3), (banana, 2)] # 还能与集合运算结合 counter1 Counter({apple: 3, banana: 2}) counter2 Counter({apple: 2, pear: 4}) print(counter1 counter2) # Counter({apple: 5, pear: 4, banana: 2})实际处理日志、词频统计、舆情关键词分析时Counter配上一行most_common(n)比手写排序省掉好几个数量级的代码量。我不止一次在代码评审里看到有人写“手动字典排序”实现词频统计其实一行Counter就能解决。4.3 字典和集合的底层机制哈希、冲突、扩容与顺序保证进阶绕不开原理。刚才提到了哈希表现在深入一点CPython的字典底层由两个核心数组组成——一个存索引indices一个存真正的键值对条目entries。哈希值算出来后先跟掩码做按位与得到数组下标如果该位置已有元素就发生了“哈希冲突”。CPython处理冲突的方案是“开放寻址法”当一个槽位被占用时它会在数组中按一定探测顺序继续找下一个空位。Python 3.7之后entries数组的存储顺序是插入顺序所以普通字典“天然保序”它靠的是“紧凑哈希表compact dict”设计——索引数组和条目数组分离插入顺序被记录在条目数组里。这也是为什么dict遍历结果始终跟插入顺序一致的原因之一。扩容发生时字典会按接近2倍的大小重建整张哈希表重新计算所有键的位置。这个过程是 O(n) 的但均摊到每次插入操作上依然是 O(1)。实际使用中如果你提前知道要存海量数据可以在构造时指定容量减少扩容次数# 注意这只是给解释器的提示不是精确预分配 big_dict dict.fromkeys(range(100000), 0) # 实际开发里优先考虑容量预估集合的底层比字典简单因为它只需要存元素本身不需要存对应的值。它的扩容和冲突处理逻辑与字典基本类似但更精简因此同样的元素量集合的内存占用通常比字典小。4.4 性能实战为什么“in”操作set比list快那么多很多人在实际代码里用if item in my_list做判断当列表长度上万时性能差异立刻显现。我做过一个简单的基准测试import time data_list list(range(100000)) data_set set(data_list) target 99999 start time.perf_counter() for _ in range(1000): target in data_list print(list查找耗时:, time.perf_counter() - start) start time.perf_counter() for _ in range(1000): target in data_set print(set查找耗时:, time.perf_counter() - start)在我的机器上集合查找比列表快大约三到四个数量级。原因前面已经说了列表是扫描集合是直接算哈希定位。列表越大差距越明显。除了查找另一个常见性能场景是去重。用集合去重一行list(set(items))就能完成但有一个副作用——如果items是列表去重后的顺序“不保证与原来一致”。需要保持顺序时可以用下面这个常见技巧def unique_preserve_order(items): seen set() result [] for item in items: if item not in seen: seen.add(item) result.append(item) return result items [苹果, 香蕉, 苹果, 橘子, 香蕉] print(unique_preserve_order(items)) # [苹果, 香蕉, 橘子]这种“集合做判断 列表保顺序”的组合是我处理大量需要去重且必须保持逻辑顺序的数据时的首选。5. 常见问题与排查技巧实录5.1 资深开发者也会踩的Dict/Set经典坑坑一可变对象作为字典键或集合元素。字典的键必须可哈希这是字典能工作的前提。但“可哈希”和“可变”天然矛盾——一个对象如果内容随时会变它算出来的哈希值就可能跟着变。所以列表、字典都不能做键尝试会直接抛TypeError: unhashable type: list。很多人遇到这个报错第一反应是“Python为什么这么讨厌”实际上这是保护你不写出逻辑错误的行为。遇到这种情况把列表转成元组再当键即可。坑二fromkeys配合可变默认值。前面提过dict.fromkeys(keys, [])会让所有键共享同一个空列表keys [a, b, c] result dict.fromkeys(keys, []) result[a].append(1) print(result) # {a: [1], b: [1], c: [1]} ← 你只改了ab和c跟着变了这个坑非常隐蔽因为报错是不存在的只有运行结果不符合预期。先想想为什么会这样fromkeys的第二个参数是同一个对象引用所有键都指向它。正确做法是defaultdict(list)或者对每个键单独创建新列表。坑三浮点数作为键的哈希精度问题。0.1 0.2不等于0.3这个经典问题在字典里同样存在。如果用浮点数做键可能出现“存的时候是这个值、取的时候用另一个看起来一样但哈希值不同的值”导致取不到。尽量避免直接用浮点数做字典键非要存数值可以用Decimal或者把浮点数转成字符串做键。坑四集合去重后顺序莫测。set本身就是无序的去重后顺序跟数据的哈希值相关完全不可预测。业务对顺序有要求时必须用unique_preserve_order这类保持顺序的手段。5.2 内存与性能排查怎么判断是数据结构选型问题遇到程序变慢很多人第一反应是找算法第二反应是看循环但很少想到“数据结构选型错了”。这里分享一个排查思路。先用tracemalloc或objgraph看看到底哪些结构占用了大量内存。某个对象数量飙升而应用又没太大的数据量往往就是结构使用不当。比如用列表装了大量需要去重的数据而且反复做in判断基本可以确定应该换成集合。再用简单的计时工具比较同一段逻辑用不同结构的耗时不需要花里胡哨的分析工具time.perf_counter就够了逻辑对不对、耗时差距有多大跑一遍便知。如果已经决定了用字典还可以看看键的选择是否合理。字符串键和整数键哈希计算成本不同整数做键通常更快。实际开发中把user_id从字符串标准化成整数再做字典键虽然收益不算夸张但数据量大的时候确有提升。5.3 几个值得记住的底层行为CPython的字典在Python 3.7保证迭代顺序与插入顺序一致但这不是“字典的本质特性”这是实现细节。写代码时不要依赖顺序去做“最后插入的是什么”之类的假设除非你清楚自己在用3.7且不会跨版本部署。集合没有保序特性。对集合做遍历时结果顺序在你看来是“随机的”这受哈希函数、初始容量、插入历史的影响。所以千万别写依赖集合遍历顺序的代码一旦数据变了顺序就变了查错会查到你怀疑人生。字典和集合在迭代过程中不能安全地改变大小违反会得到类似RuntimeError: dictionary changed size during iteration的报错。遇到这个错别慌前面给的方法——收集待删除键、循环外统一删除——就是标准解法。5.4 我的三个实操心得最后分享几个基于实际项目的心得。第一个是“能查别扫”的思维转换。写代码时只要出现 “在列表里找东西” 的直觉先停一下想想要不要用set或dict。这个习惯带来的性能收益远比折腾各种循环优化大得多。第二个是“用defaultdict替代手写缺失判断”。代码评审里看到最多的问题之一就是“先if key not in dict再赋值”这种写法它本身没错但啰嗦且容易出错。defaultdict专门解决这类问题该用就用。第三个是“熟记set的四种运算符号”。很多人把集合当成高级列表用只会add和remove完全不知道|-^的存在。实际做数据分析、权限判断时这四个符号一行顶十行优先级非常高。在这几个知识点的实际应用上我认为最值得投入时间的地方是理解“一致性哈希”与“冲突处理”这两个概念——因为数据结构选型的所有判断最终都落回到你对自己数据的预估元素量多大、查找多频繁、顺序重不重要、值需不需要做键。想清楚这几个变量选型就不会跑偏。如果你在写代码的过程中也遇到了类似的坑或者有自己的选型心得欢迎按这套思路试试大概率能在性能上看到立竿见影的变化。