先说一个我经常用来“劝退”新人的问题为什么[1, 2] [3, 4]能拼成一个[1, 2, 3, 4]而{1, 2} {3, 4}一执行就抛TypeError: unsupported operand type(s) for : set and set再问一个进阶版为什么(1, 2) * 3能自然地产出一个新元组而[[]] * 3每次看结果都对真去改数据时才炸这两个问题背后都是 Python 核心容器类型的运算机制在起作用。这篇文章就是专门梳理这件事的list、tuple、dict、set 这些核心容器的拼接、重复、成员判断、合并、集合运算到底在底层怎么运作哪些行为和直觉不一致以及我在真实项目里踩过的那些“看着没问题、跑起来全是坑”的场景。不管你是刚入门想搞懂容器还是写了好几年 Python 想系统过一遍运算机制这篇都值得花十分钟看完。1. 先把最底层的机制讲清楚运算符在 Python 里其实是一次方法调用1.1 一个加号两种命运list 能拼接set 为什么不行Python 里几乎所有运算符都不是“语法糖”那么简单它背后对应的是类型上定义的特殊方法也就是双下划线方法。当你写下a b时Python 实际会尝试调用a.__add__(b)如果a没有实现这个方法就尝试b.__radd__(a)两边都没有就直接抛TypeError。这就是[1, 2] [3, 4]能跑而{1, 2} {3, 4}不能跑的根本原因list 实现了__add__set 没有实现__add__。你在 REPL 里可以验证 [1, 2] [3, 4] [1, 2, 3, 4] {1, 2} {3, 4} Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for : set and setset 没有加号不代表它不能做“合并”这件事它实现的是__or__方法所以{1, 2} | {3, 4}就能得到{1, 2, 3, 4}。这个差异初看是“API 设计不同”本质上是“定义了不同的双下划线方法”。理解这一层很多报错就不再是玄学。你看到一个对象支持什么运算不必靠死记直接查这个类型实现了哪些魔法方法就行。1.2 每个容器类型都有一套自己的“运算方法清单”下面这张表是常用容器和它们实现的主要运算方法的对照。不需要背但建议把“每个容器实现了什么方法”当成一个整体框架去理解。容器类型支持的主要运算对应的双下划线方法list,*,in,,, 切片__add__,__mul__,__contains__,__eq__,__lt__,__getitem__tuple,*,in,,, 切片同 list但没有就地修改相关方法dictin,,|(3.9)__contains__,__eq__,__or__set,|,-,^,in,,,__and__,__or__,__sub__,__xor__,__contains__,__eq__,__le__,__lt__注意几个有意思的点dict 和 set 都实现了__contains__所以都能用in判断成员但底层一个是哈希表查找一个是哈希集合查找复杂度都是 O(1)。list 和 tuple 也有__contains__但它们是线性扫描复杂度 O(n)。这个问题我会在第二章详细展开。还有个容易忽略的set 实现了__le__和__lt__所以{1, 2} {1, 2, 3}是合法的子集判断返回True而 list 虽然也实现了__lt__但那是“字典序比较”不是子集判断。同一个符号在不同容器上含义完全不同这正是容器运算机制里最有意思的部分。1.3 了解运算机制比硬背结论更重要我见过不少新手背结论背的是“set 支持交并差list 支持拼接”真到项目里一遇到异常行为就懵。举一个现实中经常碰到的场景你定义了一个自定义类想让两个对象可以做obj1 obj2于是实现了__add__。运行后你却发现在某些场景下报错提示找不到__radd__。原因就是前面说的运算解析顺序Python 先找左操作数的__add__如果左操作数的方法返回了NotImplemented才会回头找右操作数的__radd__。容器类型本身很少涉及__radd__的使用但理解这个机制能帮你排查很多边界情况。比如你写(1, 2) [3]时Python 先尝试 tuple 的__add__发现右侧不是 tuple返回NotImplemented再尝试 list 的__radd__list 也没实现于是报错。整个过程看起来是一个TypeError背后的机制其实是两级方法查找。所以我的建议是遇到容器运算看不懂先别急着骂“Python 有病”打开 REPL 用dir(type对象)看看它实现了哪些双下划线方法基本就能明白三分。2. list 与 tuple 的运算性格拼接、乘法、切片里的那些坑2.1 和 * 产生新对象但 在 list 和 tuple 里的走向完全不同list 和 tuple 都支持和*都返回一个新的容器对象原对象不受影响。这一点很多文章都讲过真正被忽略的是的行为差异。list 实现了__iadd__所以a b实际上是在原列表上就地扩展相当于a.extend(b)a的内存地址不会变所有引用a的变量都会看到新增的元素。tuple 没有实现__iadd__所以a b会被翻译成a a b生成一个新元组再赋给a其他引用旧元组的变量不会看到变化。a [1, 2] b a a [3] print(b) # [1, 2, 3]因为 list 的 是就地修改 a (1, 2) b a a (3,) print(b) # (1, 2)因为 tuple 的 会创建新对象这在实际项目里会引发一种很隐蔽的 bug函数里对参数做了param item如果传进来的是 list调用方数据会莫名其妙被改动如果是 tuple则影响不到外部。放进同一套代码逻辑里容器类型一变副作用行为就完全不一样。我的建议是函数内部如果要修改入参明确用extend或重新赋值不要依赖的隐式语义。2.2 成员判断 in 的复杂度线性扫描与哈希查找的差距x in list和x in tuple都是线性扫描从头到尾逐个比较时间复杂度 O(n)。x in set和x in dict判断键是哈希查找时间复杂度 O(1)。这个差异平时写小脚本感觉不出来一旦数据量上来差距是肉眼可见的。我之前处理过一个日志去重的任务里面有大概 20 万个 ID刚开始用 list 存“已见过的 ID”每来一个 ID 就if id in seen。结果程序跑了十几分钟没跑完换成 set 之后秒级就出结果了。判断成员这个操作是容器选型时最容易被忽略的维度。很多人只考虑“我需不需要顺序、需不需要键值对应”忽略了“我频繁做 in 判断时底层是 O(1) 还是 O(n)”。记住了频繁 in 判断的集合优先 set频繁按键取值的用 dict。2.3 [[0]] * 3 不是三个独立子列表而是三个相同的引用这是 Python 容器乘法里最出名的一个坑。我第一次踩它是在写一个二维矩阵初始化的时候matrix [[0] * 3] * 3 matrix[0][0] 1 print(matrix) # 输出 [[1, 0, 0], [1, 0, 0], [1, 0, 0]]结果不是我预期的[[1, 0, 0], [0, 0, 0], [0, 0, 0]]而是三个子列表一起被改了。原因在于*运算符执行的是“外层容器元素的重复”而不是“对元素做深拷贝”。[0] * 3里元素是整数整数不可变没有问题[[0] * 3] * 3里元素是列表对象重复的是同一个列表对象的引用。正确的写法是用列表推导式matrix [[0] * 3 for _ in range(3)]这里的for _ in range(3)每次都会执行一次[0] * 3生成三个互不干扰的子列表。这个坑的本质又可以回溯到第一章的机制理解*调用的是__mul__它的语义是“重复引用”不是“复制内容”。2.4 切片返回新容器却是浅拷贝 比较又要求“类型一致”切片lst[1:]会返回一个新 listtuple 切片返回新 tuple这是很多人知道的。但“新容器”不等于“里面的元素也是新的”。lst [[1], [2], [3]] sub lst[1:] sub[0].append(99) print(lst) # [[1], [2, 99], [3]]原列表也变了切片只拷贝了顶层容器结构内层对象依然是引用。如果内层也是可变容器想彻底独立需要copy.deepcopy。这个特点在数据清洗、分片处理任务里很常见你切了一段数据出来改结果把原始数据也改了排查起来相当费劲。再说比较list 和 tuple 的都是逐元素递归比较但前提是类型一致。[1, 2] (1, 2)结果是False哪怕元素完全一样类型不同就是不同。很多从其他语言转过来的朋友会在这里犯嘀咕但 Python 就是这样设计的容器比较是“值和结构”的双重比较类型是隐含的硬约束。3. dict 的运算逻辑从键查找、合并运算符到哈希约束3.1 in 判断的是键不是值哈希查找的复杂度是 O(1)dict 的in运算符检查的是“键是否存在”不是“值是否存在”。这是新手最容易搞混的语义。d {name: 张三, age: 25} name in d # True因为 name 是键 张三 in d # False因为 张三 是值不是键如果你要判断值是否存在必须遍历张三 in d.values()。这也说明 dict 的__contains__是基于键哈希的所以无论 dict 多大判断键是否存在的耗时基本恒定。反过来遍历d.values()再判断就是 O(n) 了。了解这个差异写代码时就能更精准地表达意图。比如一个订单表你想知道某个“订单 ID”在不在字典里应该直接if order_id in order_dict:而不是if order_id in list(order_dict.keys()):。后者不仅先转成 list 浪费内存还把一个 O(1) 操作硬生生变成了 O(n)。3.2 合并 dict 的几种写法|、|、{**d1, **d2} 与 update 的取舍Python 3.9 引入了 dict 的合并运算符|给“合并两个字典”这件事提供了最顺手的语法。之前更常见的是{**d1, **d2}或者d1.update(d2)。几种写法的区别如下表写法位置是否产生新对象说明d1 | d23.9是新 dict右侧字典的键值覆盖左侧d1 | d23.9否就地更新相当于d1.update(d2){**d1, **d2}任意版本是新 dict展开后合并右侧覆盖左侧d1.update(d2)任意版本否就地更新最常见的就地合并方式左右覆盖顺序很好记写在一起时右边的优先级高。{a: 1} | {a: 2}结果是{a: 2}。我在实际项目里的经验是如果只是合并一次且不想影响原字典用d1 | d2最简洁如果是累积更新比如循环里不断合并用update性能更好因为省去了反复创建新对象。这个选择跟“传值还是传引用”的设计意图要一致不能在函数里想改原数据又写成d d | new_data结果函数返回了但调用方手里的 dict 没变。3.3 True 和 1 是同一个键哈希与相等性的“身份错位”dict 的键查找本质是“先比哈希值再比相等性”。这就导致一个很有趣的现象True和1的哈希值相同而且True 1成立所以它们不能同时作为不同的键。d {} d[True] yes d[1] no print(d) # {True: no}1 覆盖了 True 对应的值同样的问题也出现在0和False之间还有1和1.0之间。整数、浮点数、布尔值在哈希层面会发生“相等则视为同一键”的合并。这不是 bug而是哈希表机制的必然结果。这个坑在配置文件解析、状态字典的场景里最容易出现。比如你用status_dict {1: active, 0: inactive}存状态码还好但如果你同时想存True和1对应的不同含义就会被静默覆盖。我的建议是明确区分布尔键和数值键要么统一用枚举、字符串作为键要么做键时把布尔值显式转换掉。3.4 可哈希是 dict 键的基础约束也是自定义对象最常踩的坑dict 的键必须是可哈希的。list、dict、set 这些可变容器不可哈希不能作为键tuple 可以但前提是 tuple 内容里的元素全部可哈希。good_key (a, b) # 可以 bad_key (a, [1, 2]) # TypeError: unhashable type: list为什么因为可变对象的哈希值不稳定。一个 list 如果被当作键它的内容一变哈希值就变了字典就再也找不到这个键了。Python 干脆规定可变容器不可哈希从根上堵死这个隐患。自定义类的对象要做 dict 键时也要小心。如果你重写了__eq__Python 会自动把__hash__设为None对象变成不可哈希。正确的做法是同时重写__eq__和__hash__并且保证“相等的对象哈希值必须相同”否则会出现“键在字典里但in判断找不到”的诡异 bug。4. set 的集合运算支持 、|、-、^却偏偏不支持 和 *4.1 set 为什么不支持 和 *无序容器给拼接和重复出了道无解题set 没有实现__add__和__mul__这是它不支持和*的直接原因。但更底层的设计逻辑是拼接语法天然假设“左侧在前、右侧在后”而 set 是无序的谁前谁后没有意义*重复意味着把同一批元素复制 n 份但 set 要求元素唯一重复之后依然只有一个副本这个操作基本上没有应用场景。想合并 set正确姿势是|或union()a {1, 2} b {2, 3} print(a | b) # {1, 2, 3} print(a.union(b)) # {1, 2, 3}这里有个规律值得总结set 的“合并”对应__or__“交叠”对应__and__“减法”对应__sub__“对称差”对应__xor__。它把整套数学集合运算映射到了位运算符上思路在 Python 容器里独树一帜。4.2 、|、-、^ 各自返回新集合运算符两侧必须是 setset 的四个核心运算符含义分别是交集、并集、差集、对称差集运算符方法运算结果示例a ba.intersection(b)交集{1, 2} {2, 3}-{2}a | ba.union(b)并集{1, 2} | {2, 3}-{1, 2, 3}a - ba.difference(b)差集{1, 2} - {2, 3}-{1}a ^ ba.symmetric_difference(b)对称差集{1, 2} ^ {2, 3}-{1, 3}这几个运算符有一个共同点都返回新 set原 set 不变。如果要就地更新用对应的就地版本,|,-,^。一个容易踩的细节是运算符两侧都要求是 set 类型但同名方法可以接受任意可迭代对象。{1, 2}.union([2, 3]) # 可行因为方法内部会做转换 {1, 2} | [2, 3] # TypeError: unsupported operand type(s) for |: set and list这在代码里是个很隐蔽的坑看着差不多的写法一个能跑一个不能跑。我自己的习惯是能确定两侧都是 set 时用运算符可能混入 list、tuple 时用方法形式既避免报错也省去显式转换。4.3 子集判断、去重与空集{} 不是空集合set 支持和做子集与真子集判断做集合相等判断。a {1, 2} b {1, 2, 3} a b # True a b # True a b # False这里需要特别提醒一个经典坑空集合不是{}而是set()。{}在 Python 里是空字典。这个坑在初始化集合和函数默认参数里特别容易出现def clean(items, blacklist{}): # 这是 dict不是 set如果你把{}当成空集合传入后续调add会直接AttributeError因为 dict 没有add方法。想让函数默认集合是空集必须写成blacklistNone再在函数体内转成set()。这种细节特别小但会让初看代码的人一头雾水。4.4 元素必须可哈希list 进不了 setfrozenset 才适合当键set 和 dict 一样底层依赖哈希表所以元素必须是可哈希的。list 不可哈希不能放进 settuple 可哈希但如果 tuple 内部有 list 也不可哈希。s {(1, 2)} # 可以 s {([1, 2],)} # TypeError: unhashable type: list另一个容易忽略的是 frozenset。它是 set 的不可变版本可哈希所以可以放进 set 或作为 dict 的键。当你需要“把一组标签作为一个整体键”时frozenset 是很好用的工具s {frozenset({1, 2}), frozenset({3, 4})} # 元素也是集合的集合这比用 list 或可变 set 做嵌套结构安全得多。5. 跨界运算与拷贝问题五个最容易翻车的场景5.1 不同类型的容器直接拼装报错是第一反应转换才是正解list 和 tuple 之间不能直接相加dict 之间在 3.9 以前也不能用set 和 list 当然更不行。跨类型拼装正确的路径是先做显式转换。lst [1, 2] tpl (3, 4) # lst tpl # TypeError lst list(tpl) # [1, 2, 3, 4] s {1, 2} lst2 [3, 4] # s | lst2 # TypeError s | set(lst2) # {1, 2, 3, 4}显式转类型看起来多写一步但好处是代码意图非常清楚你想让被转换的一方变成什么类型读者一眼就懂。曾经见过有人为了实现 list 和 set 的合并先遍历再逐一add绕了一大圈。其实一步set(list) | other_set就解决了。5.2 并没有复制列表浅拷贝和深拷贝要分清b a只是给同一个对象贴了第二个名字不是复制。修改ba也会变。a [1, 2] b a b.append(3) print(a) # [1, 2, 3]真正的复制有三种切片a[:]、copy.copy(a)、copy.deepcopy(a)。其中切片和copy.copy是浅拷贝只复制顶层deepcopy递归复制所有嵌套层。这个点对函数入参特别重要。Python 传参本质是传引用如果你在函数里直接data.append(...)或data[0] ...调用方的数据会被修改。如果这不符合设计意图进函数第一步就用data data[:]或copy.deepcopy(data)生成副本。我在写数据清洗脚本时这个习惯帮我避开了很多“改着改着原始表就变了”的灾难。5.3 链式比较比你想的更聪明也更危险Python 支持链式比较a in b c在语义上等价于a in b and b c而不是(a in b) c。这个特性在处理容器时会造成代码歧义x 1 s [1, 2] # x in s True 实际上等价于 x in s and s True # 结果是 False因为 s True 是 False如果你本意是判断(x in s) True请务必加括号。这种写法在真实项目里很少见但一旦出现排查起来极其痛苦因为逻辑读上去和你想的完全不一样。我的建议是链式比较只用于数值范围判断比如0 x 10涉及容器成员判断的场景一律显式加括号。5.4 去重会打乱顺序保序去重要用 dict.fromkeysset(items)是最简单粗暴的去重方式但它不保留原始顺序因为 set 本身是无序的。如果你的业务要求“保留第一次出现的顺序”直接 set 去重就会出问题。保序去重的标准做法是利用 dict 键的唯一性加有序性Python 3.7 以后 dict 保持插入顺序items [3, 1, 3, 2, 1, 2] unique list(dict.fromkeys(items)) print(unique) # [3, 1, 2]dict.fromkeys(items)会把 list 的每个元素作为键重复元素自动覆盖因为 dict 按键去重并且保持第一次插入的顺序最后list()取回键列表。这套写法比“set 再排序”要稳定得多尤其是当元素是自定义对象、排序本身没有意义的时候。5.5 空容器的布尔值全是 False判断键用 in 而不是 get空 list、空 tuple、空 dict、空 set、空字符串在布尔上下文中都是False。所以if not container:可以直接判断“容器是否为空”这是 Python 的惯用写法。但这里藏着一个和 dict 相关的坑如果你用if d.get(key):来判断“键是否存在且值非空”当键存在但值是0、False、None、空字符串时判断会误判为“键不存在或值为空”。判断 key 本身存在与否应该用if key in d:。d {count: 0} # 错误写法 if d.get(count): print(有值) # 不触发因为 0 是假值 # 正确写法 if count in d: print(键存在)这个坑在处理“数量 0”“关闭状态 False”这类语义时特别容易踩。记住一个原则判断成员用in取值附带默认值才用get。6. 排坑之后我养成的几个习惯6.1 写容器运算之前先在脑子里过一遍“底层调用了哪个方法”现在写a b、a b、a | b这类代码时我都会下意识想一下这个类型实现了对应的双下划线方法吗如果没实现报错会在哪一步这个方法返回新对象还是就地修改这样想一遍至少能提前排除掉一半以上的低级错误。6.2 高频成员判断优先考虑 set 或 dict写爬虫去重、日志查重、ID 过滤这类代码时我默认用 set 而不是 list。判断一个元素在不在容器里set/dict 的 O(1) 和 list 的 O(n) 在大数据量下差距巨大。实测过十万级别的数据list 的 in 判断耗时大约是 set 的几十倍这个差距在循环嵌套场景下会被进一步放大。6.3 分清“返回新容器”和“修改原容器”这两类 APIsorted(l)返回新 listl.sort()就地排序。d1 | d2返回新 dictd1.update(d2)就地更新。s.union(other)返回新 sets.update(other)就地更新。lst.append(x)就地修改lst [x]返回新 list。记不住的时候优先查文档拿不准的时候在副本上操作。这两条准则能在团队协作里少给别人添很多麻烦。6.4 一条代码审查时常用的自查清单我整理了一张常用的容器运算自查清单每次 code review 时都会对照检查一遍检查项典型问题正确做法乘法初始化嵌套容器[[0]] * 3导致引用共享用列表推导式默认参数用可变容器def f(x[])导致状态累积默认参数设为None内部再创建list 频繁 in 判断数据量大时性能差改用 set 或拆到 dict 的键用于函数入参修改了调用方数据或 tuple 生成新对象明确用extend或重赋值if d.get(key)判断键存在值为0/False/None时误判用if key in d运算符两侧容器类型不一致set | list抛 TypeError先用set()转换再运算浅拷贝当作深拷贝嵌套容器被连带修改需要完全独立时用deepcopy我自己入行那会儿也曾在[[]] * 3这个坑里交过一份带 bug 的代码排查了整整一个下午。后来养成习惯写容器运算时先默想它底层调用了什么方法再确认它是返回新对象还是修改原对象。看似每一步都多花了几秒钟但真的能帮你躲过绝大多数坑。Python 容器的运算机制其实不复杂复杂的是你从来没停下来想过“运算符背后发生了什么”。把这层窗户纸捅破之后不管遇到多冷门的组合报错你都能从“方法清单”这个根上找到解释。 
长河君 · 2026/10/6 4:58:29 · 阅读 1.2k Python容器运算机制：list/tuple/dict/set的差异与避坑
先说一个我经常用来“劝退”新人的问题为什么[1, 2] [3, 4]能拼成一个[1, 2, 3, 4]而{1, 2} {3, 4}一执行就抛TypeError: unsupported operand type(s) for : set and set再问一个进阶版为什么(1, 2) * 3能自然地产出一个新元组而[[]] * 3每次看结果都对真去改数据时才炸这两个问题背后都是 Python 核心容器类型的运算机制在起作用。这篇文章就是专门梳理这件事的list、tuple、dict、set 这些核心容器的拼接、重复、成员判断、合并、集合运算到底在底层怎么运作哪些行为和直觉不一致以及我在真实项目里踩过的那些“看着没问题、跑起来全是坑”的场景。不管你是刚入门想搞懂容器还是写了好几年 Python 想系统过一遍运算机制这篇都值得花十分钟看完。1. 先把最底层的机制讲清楚运算符在 Python 里其实是一次方法调用1.1 一个加号两种命运list 能拼接set 为什么不行Python 里几乎所有运算符都不是“语法糖”那么简单它背后对应的是类型上定义的特殊方法也就是双下划线方法。当你写下a b时Python 实际会尝试调用a.__add__(b)如果a没有实现这个方法就尝试b.__radd__(a)两边都没有就直接抛TypeError。这就是[1, 2] [3, 4]能跑而{1, 2} {3, 4}不能跑的根本原因list 实现了__add__set 没有实现__add__。你在 REPL 里可以验证 [1, 2] [3, 4] [1, 2, 3, 4] {1, 2} {3, 4} Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for : set and setset 没有加号不代表它不能做“合并”这件事它实现的是__or__方法所以{1, 2} | {3, 4}就能得到{1, 2, 3, 4}。这个差异初看是“API 设计不同”本质上是“定义了不同的双下划线方法”。理解这一层很多报错就不再是玄学。你看到一个对象支持什么运算不必靠死记直接查这个类型实现了哪些魔法方法就行。1.2 每个容器类型都有一套自己的“运算方法清单”下面这张表是常用容器和它们实现的主要运算方法的对照。不需要背但建议把“每个容器实现了什么方法”当成一个整体框架去理解。容器类型支持的主要运算对应的双下划线方法list,*,in,,, 切片__add__,__mul__,__contains__,__eq__,__lt__,__getitem__tuple,*,in,,, 切片同 list但没有就地修改相关方法dictin,,|(3.9)__contains__,__eq__,__or__set,|,-,^,in,,,__and__,__or__,__sub__,__xor__,__contains__,__eq__,__le__,__lt__注意几个有意思的点dict 和 set 都实现了__contains__所以都能用in判断成员但底层一个是哈希表查找一个是哈希集合查找复杂度都是 O(1)。list 和 tuple 也有__contains__但它们是线性扫描复杂度 O(n)。这个问题我会在第二章详细展开。还有个容易忽略的set 实现了__le__和__lt__所以{1, 2} {1, 2, 3}是合法的子集判断返回True而 list 虽然也实现了__lt__但那是“字典序比较”不是子集判断。同一个符号在不同容器上含义完全不同这正是容器运算机制里最有意思的部分。1.3 了解运算机制比硬背结论更重要我见过不少新手背结论背的是“set 支持交并差list 支持拼接”真到项目里一遇到异常行为就懵。举一个现实中经常碰到的场景你定义了一个自定义类想让两个对象可以做obj1 obj2于是实现了__add__。运行后你却发现在某些场景下报错提示找不到__radd__。原因就是前面说的运算解析顺序Python 先找左操作数的__add__如果左操作数的方法返回了NotImplemented才会回头找右操作数的__radd__。容器类型本身很少涉及__radd__的使用但理解这个机制能帮你排查很多边界情况。比如你写(1, 2) [3]时Python 先尝试 tuple 的__add__发现右侧不是 tuple返回NotImplemented再尝试 list 的__radd__list 也没实现于是报错。整个过程看起来是一个TypeError背后的机制其实是两级方法查找。所以我的建议是遇到容器运算看不懂先别急着骂“Python 有病”打开 REPL 用dir(type对象)看看它实现了哪些双下划线方法基本就能明白三分。2. list 与 tuple 的运算性格拼接、乘法、切片里的那些坑2.1 和 * 产生新对象但 在 list 和 tuple 里的走向完全不同list 和 tuple 都支持和*都返回一个新的容器对象原对象不受影响。这一点很多文章都讲过真正被忽略的是的行为差异。list 实现了__iadd__所以a b实际上是在原列表上就地扩展相当于a.extend(b)a的内存地址不会变所有引用a的变量都会看到新增的元素。tuple 没有实现__iadd__所以a b会被翻译成a a b生成一个新元组再赋给a其他引用旧元组的变量不会看到变化。a [1, 2] b a a [3] print(b) # [1, 2, 3]因为 list 的 是就地修改 a (1, 2) b a a (3,) print(b) # (1, 2)因为 tuple 的 会创建新对象这在实际项目里会引发一种很隐蔽的 bug函数里对参数做了param item如果传进来的是 list调用方数据会莫名其妙被改动如果是 tuple则影响不到外部。放进同一套代码逻辑里容器类型一变副作用行为就完全不一样。我的建议是函数内部如果要修改入参明确用extend或重新赋值不要依赖的隐式语义。2.2 成员判断 in 的复杂度线性扫描与哈希查找的差距x in list和x in tuple都是线性扫描从头到尾逐个比较时间复杂度 O(n)。x in set和x in dict判断键是哈希查找时间复杂度 O(1)。这个差异平时写小脚本感觉不出来一旦数据量上来差距是肉眼可见的。我之前处理过一个日志去重的任务里面有大概 20 万个 ID刚开始用 list 存“已见过的 ID”每来一个 ID 就if id in seen。结果程序跑了十几分钟没跑完换成 set 之后秒级就出结果了。判断成员这个操作是容器选型时最容易被忽略的维度。很多人只考虑“我需不需要顺序、需不需要键值对应”忽略了“我频繁做 in 判断时底层是 O(1) 还是 O(n)”。记住了频繁 in 判断的集合优先 set频繁按键取值的用 dict。2.3 [[0]] * 3 不是三个独立子列表而是三个相同的引用这是 Python 容器乘法里最出名的一个坑。我第一次踩它是在写一个二维矩阵初始化的时候matrix [[0] * 3] * 3 matrix[0][0] 1 print(matrix) # 输出 [[1, 0, 0], [1, 0, 0], [1, 0, 0]]结果不是我预期的[[1, 0, 0], [0, 0, 0], [0, 0, 0]]而是三个子列表一起被改了。原因在于*运算符执行的是“外层容器元素的重复”而不是“对元素做深拷贝”。[0] * 3里元素是整数整数不可变没有问题[[0] * 3] * 3里元素是列表对象重复的是同一个列表对象的引用。正确的写法是用列表推导式matrix [[0] * 3 for _ in range(3)]这里的for _ in range(3)每次都会执行一次[0] * 3生成三个互不干扰的子列表。这个坑的本质又可以回溯到第一章的机制理解*调用的是__mul__它的语义是“重复引用”不是“复制内容”。2.4 切片返回新容器却是浅拷贝 比较又要求“类型一致”切片lst[1:]会返回一个新 listtuple 切片返回新 tuple这是很多人知道的。但“新容器”不等于“里面的元素也是新的”。lst [[1], [2], [3]] sub lst[1:] sub[0].append(99) print(lst) # [[1], [2, 99], [3]]原列表也变了切片只拷贝了顶层容器结构内层对象依然是引用。如果内层也是可变容器想彻底独立需要copy.deepcopy。这个特点在数据清洗、分片处理任务里很常见你切了一段数据出来改结果把原始数据也改了排查起来相当费劲。再说比较list 和 tuple 的都是逐元素递归比较但前提是类型一致。[1, 2] (1, 2)结果是False哪怕元素完全一样类型不同就是不同。很多从其他语言转过来的朋友会在这里犯嘀咕但 Python 就是这样设计的容器比较是“值和结构”的双重比较类型是隐含的硬约束。3. dict 的运算逻辑从键查找、合并运算符到哈希约束3.1 in 判断的是键不是值哈希查找的复杂度是 O(1)dict 的in运算符检查的是“键是否存在”不是“值是否存在”。这是新手最容易搞混的语义。d {name: 张三, age: 25} name in d # True因为 name 是键 张三 in d # False因为 张三 是值不是键如果你要判断值是否存在必须遍历张三 in d.values()。这也说明 dict 的__contains__是基于键哈希的所以无论 dict 多大判断键是否存在的耗时基本恒定。反过来遍历d.values()再判断就是 O(n) 了。了解这个差异写代码时就能更精准地表达意图。比如一个订单表你想知道某个“订单 ID”在不在字典里应该直接if order_id in order_dict:而不是if order_id in list(order_dict.keys()):。后者不仅先转成 list 浪费内存还把一个 O(1) 操作硬生生变成了 O(n)。3.2 合并 dict 的几种写法|、|、{**d1, **d2} 与 update 的取舍Python 3.9 引入了 dict 的合并运算符|给“合并两个字典”这件事提供了最顺手的语法。之前更常见的是{**d1, **d2}或者d1.update(d2)。几种写法的区别如下表写法位置是否产生新对象说明d1 | d23.9是新 dict右侧字典的键值覆盖左侧d1 | d23.9否就地更新相当于d1.update(d2){**d1, **d2}任意版本是新 dict展开后合并右侧覆盖左侧d1.update(d2)任意版本否就地更新最常见的就地合并方式左右覆盖顺序很好记写在一起时右边的优先级高。{a: 1} | {a: 2}结果是{a: 2}。我在实际项目里的经验是如果只是合并一次且不想影响原字典用d1 | d2最简洁如果是累积更新比如循环里不断合并用update性能更好因为省去了反复创建新对象。这个选择跟“传值还是传引用”的设计意图要一致不能在函数里想改原数据又写成d d | new_data结果函数返回了但调用方手里的 dict 没变。3.3 True 和 1 是同一个键哈希与相等性的“身份错位”dict 的键查找本质是“先比哈希值再比相等性”。这就导致一个很有趣的现象True和1的哈希值相同而且True 1成立所以它们不能同时作为不同的键。d {} d[True] yes d[1] no print(d) # {True: no}1 覆盖了 True 对应的值同样的问题也出现在0和False之间还有1和1.0之间。整数、浮点数、布尔值在哈希层面会发生“相等则视为同一键”的合并。这不是 bug而是哈希表机制的必然结果。这个坑在配置文件解析、状态字典的场景里最容易出现。比如你用status_dict {1: active, 0: inactive}存状态码还好但如果你同时想存True和1对应的不同含义就会被静默覆盖。我的建议是明确区分布尔键和数值键要么统一用枚举、字符串作为键要么做键时把布尔值显式转换掉。3.4 可哈希是 dict 键的基础约束也是自定义对象最常踩的坑dict 的键必须是可哈希的。list、dict、set 这些可变容器不可哈希不能作为键tuple 可以但前提是 tuple 内容里的元素全部可哈希。good_key (a, b) # 可以 bad_key (a, [1, 2]) # TypeError: unhashable type: list为什么因为可变对象的哈希值不稳定。一个 list 如果被当作键它的内容一变哈希值就变了字典就再也找不到这个键了。Python 干脆规定可变容器不可哈希从根上堵死这个隐患。自定义类的对象要做 dict 键时也要小心。如果你重写了__eq__Python 会自动把__hash__设为None对象变成不可哈希。正确的做法是同时重写__eq__和__hash__并且保证“相等的对象哈希值必须相同”否则会出现“键在字典里但in判断找不到”的诡异 bug。4. set 的集合运算支持 、|、-、^却偏偏不支持 和 *4.1 set 为什么不支持 和 *无序容器给拼接和重复出了道无解题set 没有实现__add__和__mul__这是它不支持和*的直接原因。但更底层的设计逻辑是拼接语法天然假设“左侧在前、右侧在后”而 set 是无序的谁前谁后没有意义*重复意味着把同一批元素复制 n 份但 set 要求元素唯一重复之后依然只有一个副本这个操作基本上没有应用场景。想合并 set正确姿势是|或union()a {1, 2} b {2, 3} print(a | b) # {1, 2, 3} print(a.union(b)) # {1, 2, 3}这里有个规律值得总结set 的“合并”对应__or__“交叠”对应__and__“减法”对应__sub__“对称差”对应__xor__。它把整套数学集合运算映射到了位运算符上思路在 Python 容器里独树一帜。4.2 、|、-、^ 各自返回新集合运算符两侧必须是 setset 的四个核心运算符含义分别是交集、并集、差集、对称差集运算符方法运算结果示例a ba.intersection(b)交集{1, 2} {2, 3}-{2}a | ba.union(b)并集{1, 2} | {2, 3}-{1, 2, 3}a - ba.difference(b)差集{1, 2} - {2, 3}-{1}a ^ ba.symmetric_difference(b)对称差集{1, 2} ^ {2, 3}-{1, 3}这几个运算符有一个共同点都返回新 set原 set 不变。如果要就地更新用对应的就地版本,|,-,^。一个容易踩的细节是运算符两侧都要求是 set 类型但同名方法可以接受任意可迭代对象。{1, 2}.union([2, 3]) # 可行因为方法内部会做转换 {1, 2} | [2, 3] # TypeError: unsupported operand type(s) for |: set and list这在代码里是个很隐蔽的坑看着差不多的写法一个能跑一个不能跑。我自己的习惯是能确定两侧都是 set 时用运算符可能混入 list、tuple 时用方法形式既避免报错也省去显式转换。4.3 子集判断、去重与空集{} 不是空集合set 支持和做子集与真子集判断做集合相等判断。a {1, 2} b {1, 2, 3} a b # True a b # True a b # False这里需要特别提醒一个经典坑空集合不是{}而是set()。{}在 Python 里是空字典。这个坑在初始化集合和函数默认参数里特别容易出现def clean(items, blacklist{}): # 这是 dict不是 set如果你把{}当成空集合传入后续调add会直接AttributeError因为 dict 没有add方法。想让函数默认集合是空集必须写成blacklistNone再在函数体内转成set()。这种细节特别小但会让初看代码的人一头雾水。4.4 元素必须可哈希list 进不了 setfrozenset 才适合当键set 和 dict 一样底层依赖哈希表所以元素必须是可哈希的。list 不可哈希不能放进 settuple 可哈希但如果 tuple 内部有 list 也不可哈希。s {(1, 2)} # 可以 s {([1, 2],)} # TypeError: unhashable type: list另一个容易忽略的是 frozenset。它是 set 的不可变版本可哈希所以可以放进 set 或作为 dict 的键。当你需要“把一组标签作为一个整体键”时frozenset 是很好用的工具s {frozenset({1, 2}), frozenset({3, 4})} # 元素也是集合的集合这比用 list 或可变 set 做嵌套结构安全得多。5. 跨界运算与拷贝问题五个最容易翻车的场景5.1 不同类型的容器直接拼装报错是第一反应转换才是正解list 和 tuple 之间不能直接相加dict 之间在 3.9 以前也不能用set 和 list 当然更不行。跨类型拼装正确的路径是先做显式转换。lst [1, 2] tpl (3, 4) # lst tpl # TypeError lst list(tpl) # [1, 2, 3, 4] s {1, 2} lst2 [3, 4] # s | lst2 # TypeError s | set(lst2) # {1, 2, 3, 4}显式转类型看起来多写一步但好处是代码意图非常清楚你想让被转换的一方变成什么类型读者一眼就懂。曾经见过有人为了实现 list 和 set 的合并先遍历再逐一add绕了一大圈。其实一步set(list) | other_set就解决了。5.2 并没有复制列表浅拷贝和深拷贝要分清b a只是给同一个对象贴了第二个名字不是复制。修改ba也会变。a [1, 2] b a b.append(3) print(a) # [1, 2, 3]真正的复制有三种切片a[:]、copy.copy(a)、copy.deepcopy(a)。其中切片和copy.copy是浅拷贝只复制顶层deepcopy递归复制所有嵌套层。这个点对函数入参特别重要。Python 传参本质是传引用如果你在函数里直接data.append(...)或data[0] ...调用方的数据会被修改。如果这不符合设计意图进函数第一步就用data data[:]或copy.deepcopy(data)生成副本。我在写数据清洗脚本时这个习惯帮我避开了很多“改着改着原始表就变了”的灾难。5.3 链式比较比你想的更聪明也更危险Python 支持链式比较a in b c在语义上等价于a in b and b c而不是(a in b) c。这个特性在处理容器时会造成代码歧义x 1 s [1, 2] # x in s True 实际上等价于 x in s and s True # 结果是 False因为 s True 是 False如果你本意是判断(x in s) True请务必加括号。这种写法在真实项目里很少见但一旦出现排查起来极其痛苦因为逻辑读上去和你想的完全不一样。我的建议是链式比较只用于数值范围判断比如0 x 10涉及容器成员判断的场景一律显式加括号。5.4 去重会打乱顺序保序去重要用 dict.fromkeysset(items)是最简单粗暴的去重方式但它不保留原始顺序因为 set 本身是无序的。如果你的业务要求“保留第一次出现的顺序”直接 set 去重就会出问题。保序去重的标准做法是利用 dict 键的唯一性加有序性Python 3.7 以后 dict 保持插入顺序items [3, 1, 3, 2, 1, 2] unique list(dict.fromkeys(items)) print(unique) # [3, 1, 2]dict.fromkeys(items)会把 list 的每个元素作为键重复元素自动覆盖因为 dict 按键去重并且保持第一次插入的顺序最后list()取回键列表。这套写法比“set 再排序”要稳定得多尤其是当元素是自定义对象、排序本身没有意义的时候。5.5 空容器的布尔值全是 False判断键用 in 而不是 get空 list、空 tuple、空 dict、空 set、空字符串在布尔上下文中都是False。所以if not container:可以直接判断“容器是否为空”这是 Python 的惯用写法。但这里藏着一个和 dict 相关的坑如果你用if d.get(key):来判断“键是否存在且值非空”当键存在但值是0、False、None、空字符串时判断会误判为“键不存在或值为空”。判断 key 本身存在与否应该用if key in d:。d {count: 0} # 错误写法 if d.get(count): print(有值) # 不触发因为 0 是假值 # 正确写法 if count in d: print(键存在)这个坑在处理“数量 0”“关闭状态 False”这类语义时特别容易踩。记住一个原则判断成员用in取值附带默认值才用get。6. 排坑之后我养成的几个习惯6.1 写容器运算之前先在脑子里过一遍“底层调用了哪个方法”现在写a b、a b、a | b这类代码时我都会下意识想一下这个类型实现了对应的双下划线方法吗如果没实现报错会在哪一步这个方法返回新对象还是就地修改这样想一遍至少能提前排除掉一半以上的低级错误。6.2 高频成员判断优先考虑 set 或 dict写爬虫去重、日志查重、ID 过滤这类代码时我默认用 set 而不是 list。判断一个元素在不在容器里set/dict 的 O(1) 和 list 的 O(n) 在大数据量下差距巨大。实测过十万级别的数据list 的 in 判断耗时大约是 set 的几十倍这个差距在循环嵌套场景下会被进一步放大。6.3 分清“返回新容器”和“修改原容器”这两类 APIsorted(l)返回新 listl.sort()就地排序。d1 | d2返回新 dictd1.update(d2)就地更新。s.union(other)返回新 sets.update(other)就地更新。lst.append(x)就地修改lst [x]返回新 list。记不住的时候优先查文档拿不准的时候在副本上操作。这两条准则能在团队协作里少给别人添很多麻烦。6.4 一条代码审查时常用的自查清单我整理了一张常用的容器运算自查清单每次 code review 时都会对照检查一遍检查项典型问题正确做法乘法初始化嵌套容器[[0]] * 3导致引用共享用列表推导式默认参数用可变容器def f(x[])导致状态累积默认参数设为None内部再创建list 频繁 in 判断数据量大时性能差改用 set 或拆到 dict 的键用于函数入参修改了调用方数据或 tuple 生成新对象明确用extend或重赋值if d.get(key)判断键存在值为0/False/None时误判用if key in d运算符两侧容器类型不一致set | list抛 TypeError先用set()转换再运算浅拷贝当作深拷贝嵌套容器被连带修改需要完全独立时用deepcopy我自己入行那会儿也曾在[[]] * 3这个坑里交过一份带 bug 的代码排查了整整一个下午。后来养成习惯写容器运算时先默想它底层调用了什么方法再确认它是返回新对象还是修改原对象。看似每一步都多花了几秒钟但真的能帮你躲过绝大多数坑。Python 容器的运算机制其实不复杂复杂的是你从来没停下来想过“运算符背后发生了什么”。把这层窗户纸捅破之后不管遇到多冷门的组合报错你都能从“方法清单”这个根上找到解释。