先抛个问题写Python超过一年的同学真的搞懂元组了吗我猜一大半人的答案是“元组就是不能修改的列表嘛用来放不让改的数据”。这话不能算错但基本属于把元组当成一个“阉割版列表”——完全没吃到元组的红利。元组在Python里是个非常特殊的角色它不只是保存数据更像是跟解释器签了一份“我不会变”的协议。这份协议能换来哈希能力、换来更快的访问速度、换来可以当字典key的资格同时也会给你埋下好几个超级经典的坑。这一期趣玩Python咱们就把元组从头到尾撸一遍包括创建姿势、不可变性的边界、解包技巧、和列表的性能实测以及为什么在某些场景下我强烈建议你用元组而不是列表。1. 元组的身份定位先把它和列表彻底分开1.1 元组是“记录”不是“容器”很多教材喜欢把元组说成“不可变的列表”这个说法在语法层面上没问题但它非常容易误导人。列表的核心用途是装一组“同质”的数据一整批文件名、一页的所有商品价格、一系列事件日志。这些数据数量是可变的而且你会对它们做追加、排序、筛选。列表天然就是一个“可变容器”它的容量可以随时长大。元组呢它的核心用途是表达“一条固定的记录”。比如一个二维坐标(100, 200)x和y各有各的意义拆开就没有意义再比如一个人的基本信息(王小明, 18, 高三)三个位置分别代表姓名、年龄、班级你几乎不会想在中间“插入”一项更不会想让这条记录的结构被改掉。理解了这一点你就会明白元组和列表的分工不是“一个能改一个不能改”而是“一个适合动态集合一个适合固定记录”。选型的时候先问自己这堆数据在逻辑上是要增删的还是一个不可拆分的整体前者选列表后者选元组。1.2 创建元组的全部姿势逗号才是灵魂先上代码把元组的创建方式全部过一遍# 空元组 t1 () t2 tuple() print(type(t1), len(t1)) # class tuple 0 # 装多个元素 t3 (1, 2, 3) # 最常见的写法括号用来分组 t4 1, 2, 3 # 没有括号照样是元组 print(type(t4)) # class tuple # 单元素元组一定要带逗号 t5 (42,) t6 42, print(type(t5), type(t6)) # tuple tuple # 这是整数不是元组 t7 (42) print(type(t7)) # class int这个单元素元组的坑我见过无数人踩。(42)在Python里就是一普通的整数只是被括号括了一下(42,)才是一个包含一个元素的元组。记住一句话创建元组的关键不是圆括号是逗号。圆括号只是在可读性上帮你分组真正让解释器认出“这是元组”的是那个逗号。另外还有几种创建方式# 列表转元组 t8 tuple([1, 2, 3]) # (1, 2, 3) # 字符串转元组注意会逐字符拆开 t9 tuple(abc) # (a, b, c) # range转元组 t10 tuple(range(5)) # (0, 1, 2, 3, 4)tuple()这个构造函数的参数必须是一个可迭代对象。你传入列表、字符串、range它都会一个一个元素取出来组装成元组。这个操作在你想把某些动态生成的数据“冻结”下来的时候特别好用。1.3 格式化字符串里的元组坑再补一个创建元组时很经典的应用场景老式百分号格式化。你需要把多个值塞进一个字符串模板时必须用元组name 王小明 age 18 # 正确写法多个值用元组包起来 print(姓名%s年龄%d % (name, age)) # 经典错误少包一层直接变成字符串 # print(姓名%s年龄%d % name) # TypeError: not all arguments converted...有人问单个值也要写元组吗单个值可以直接写%s % hello没问题。但哪怕是单个值如果你写成(%s % (hello,))也可以。真正的坑出现在“只有一个值但是也要用逗号”的场景比如你写(hello,)少了个逗号变成(hello)它就变成字符串 hello 本身了。这个细节在写格式化代码的时候非常容易翻车因为报错信息不一定直观有时候是结果完全不对。2. 不可变性的边界锁住了什么没锁住什么2.1 元组锁住的是“引用的指向”元组最出名的特性就是不可变不能添加元素不能删除元素不能替换某个位置的元素。如果你强行修改会直接看到那一句经典的报错t (1, 2, 3) t[0] 100 # TypeError: tuple object does not support item assignment这个报错的意思翻译成人话就是元组不支持“往指定格子塞新值”。因为元组的底层结构是一段连续的内存每个位置存的都是指向某个对象的“引用”。不可变指的是每个位置的引用不能变你不能把某个格子里的引用换成另一个对象的引用。但注意引用不能变不代表引用指向的对象不能变。这句话是理解元组不可变性的分水岭也是面试题里的常客。2.2 元组里放列表看起来就“可变”了看这个例子t (1, 2, [3, 4, 5]) t[2].append(6) print(t) # (1, 2, [3, 4, 5, 6])你没看错元组“里面”的内容变了。原因很简单元组的第三个格子始终指向那个列表对象这个引用没有变过但是列表对象本身是可变对象append(6)是在这个列表内部追加元素没有改变元组里任何格子的指向。我用一个生活化类比想象一排固定的书架格子元组保证的是“每个格子只能放固定的那一本书你不能换书”。但是如果格子里放的是一个活页夹列表这个活页夹里的纸张是可以增删的。书架结构没变但活页夹内容变了。那怎么办如果你需要“彻底不可变”的数据结构就得保证元组里每个元素也都是不可变对象数字、字符串、元组、frozenset、bytes这些都行。一旦混入列表、字典、集合这类可变对象这个元组就只能锁住“第一层”锁不住内层。写代码时如果要对内层数据递递归地保证不可变那就得自己设计拷贝策略这是很多初学函数式编程的人容易忽略的点。2.3 不可变性换来的三样好东西既然元组有这么多限制为什么还要用因为它用“不能改”换来了三个实打实的能力。第一哈希能力。不可变的对象大概率是可哈希的只要内部元素也都可哈希可哈希对象就能当字典的key、集合的元素。列表因为可变永远享受不到这个待遇。看演示# 元组可以当字典key coords {(1, 2): 东门, (3, 4): 南门} print(coords[(1, 2)]) # 东门 # 列表不行 # coords {[1, 2]: 东门} # TypeError: unhashable type: list第二安全的共享。因为内容不能变你可以放心地把同一个元组扔给多个函数、多个线程去读不用担心某个函数偷偷改掉它。列表就不行你传出去一份引用对方一个append、一个remove就能把你原来的数据改得面目全非。第三编译器的优化空间。解释器知道元组不会被修改就可以做提前缓存、紧凑存储等优化。同一份数据元组占的内存普遍比列表小访问速度也更快。这一点后面用实测数据说话。3. 解包与星号元组最好用的玩法都在这3.1 序列解包一次把值全拿干净元组最有魅力的操作不是读取而是“解开”。把元组里的元素一次性赋值给同样数量的变量就是序列解包point (100, 300) x, y point print(x, y) # 100 300 # 循环里也经常这么写 points [(1, 2), (3, 4), (5, 6)] for px, py in points: print(px, py)解包的本质是Python解释器把右侧的可迭代对象按顺序拆开然后逐一绑定到左侧的变量名。所以左侧变量的数量必须和右侧元素数量一致多一个少一个都会报错a, b (1, 2, 3) # ValueError: too many values to unpack (expected 2)这个报错在实际开发里非常常见尤其是在写函数返回值解包时。解决的办法就是下面这个星号大法。3.2 星号解包把多余数据捞进列表当你只关心元组的一部分元素时可以用*变量名来接收剩余的所有元素t (1, 2, 3, 4, 5) head, *mid, tail t print(head) # 1 print(mid) # [2, 3, 4] print(tail) # 5 first, *rest t print(first) # 1 print(rest) # [2, 3, 4, 5]注意mid和rest接收到的类型是列表不是元组。这是Python的设计习惯星号表达式用来收集“不定数量”的数据收集出来的东西天然适合放进列表。你在实际项目中最常遇到的场景是“只要首尾不要中间”这时候一行head, *_, tail t就能优雅地解决。3.3 交换变量、多返回值、*args 底层都是元组这三个看似不相关的功能底层全是元组在干活。先看交换变量a, b 1, 2 a, b b, a print(a, b) # 2 1这行a, b b, a很多人背下来了但不知道原理。其实右侧b, a会先构造出一个临时元组(2, 1)然后左侧的解包操作再把这个元组拆开分别赋给a和b。所以这行代码实际上是“创建临时元组 解包赋值”两步合体跟temp b; b a; a temp最终效果一样但写法简单得多。再看函数多返回值def min_max(nums): return min(nums), max(nums) lo, hi min_max([3, 1, 4, 1, 5]) print(lo, hi) # 1 5Python函数“返回多个值”其实是返回了一个元组。你写return min(nums), max(nums)就是把两个值打包成一个元组返回调用方再通过解包把它拆开。知道了这一点你就会明白任何返回多个值的函数本质上都是在返回元组。最后看*argsdef collect(*args): print(type(args)) # class tuple return args result collect(1, 2, 3) print(result) # (1, 2, 3)*args会把调用方传入的所有位置参数收集成一个元组。这个机制非常实用因为你在写装饰器、参数透传、日志封装这类代码时经常要接收“任意数量的参数”而元组恰好提供了不可变的容器来安全地承接这些参数。3.4 解包时的占位技巧用下划线扔掉不要的值解包时遇到你完全用不到的元素习惯性地用下划线_占位user_info (王小明, 18, 北京市海淀区) name, _, address user_info print(name, address) # 王小明 北京市海淀区Python对_并没有语言级别的特殊待遇它只是一个约定俗成的普通变量名表示“我故意不关心这个位置”。但因为这个约定太通用了很多代码检查工具都会把_当作“有意忽略”的标识不会报未使用变量警告。这个习惯建议从学元组解包第一天就养成。4. 元组 vs 列表选型真正的玄机4.1 性能实测元组凭什么更快很多人知道元组快但不知道快在哪。我先给一组实测数据。在本地64位CPythonPython 3.11环境下用timeit分别创建一万次列表和元组import timeit t_list timeit.timeit([1, 2, 3, 4, 5, 6, 7, 8, 9, 10], number1_000_000) t_tuple timeit.timeit((1, 2, 3, 4, 5, 6, 7, 8, 9, 10), number1_000_000) print(flist创建时间: {t_list:.4f}s) # 大约 0.08~0.10s print(ftuple创建时间: {t_tuple:.4f}s) # 大约 0.02~0.03s在同样的机器上元组创建时间大概是列表的四分之一到三分之一。这个差距来自几个方面一是内存布局。列表是可变的为了能在后面高效地append解释器会预先多分配一些内存空间元组不可变内部结构是“精确分配”的存几个元素就分配几块空间没有额外冗余。用sys.getsizeof可以直观看到import sys print(sys.getsizeof([1, 2, 3, 4, 5])) # 在64位CPython 3.11下大约是104字节 print(sys.getsizeof((1, 2, 3, 4, 5))) # 大约是80字节同是5个整数列表多出24字节左右的预留空间。别小看这24字节数据量大了以后累积的内存差异相当可观。二是编译期优化。在一个函数内部写return (1, 2, 3)解释器会在编译阶段就把这个元组对象建好运行时直接取出用根本不需要现场构造而return [1, 2, 3]这类写法即便是字面量也需要在运行时创建新列表对象。当然Python 3.12之后解释器对各类字面量的优化更加激进列表字面量的开销也有明显下降但元组在“固定结构”场景下的性能和内存优势依然稳定。4.2 语义差异让代码自己说明“这个数据不能改”性能只是加分项真正决定选型的还是语义。我看到太多新手项目里所有数据一律用列表哪怕这个列表从头到尾没被改过。这种做法不是不能用但它会给读代码的人传递一个错误信号既然你用了列表别人就会默认这个数据“会被添加、删除、排序”于是可能去调用一些会修改列表的方法然后引发一系列奇怪的bug。反过来如果你从一开始就把它写成元组别人一看到tuple类型就知道这个数据是固定的你别想往里塞东西。你的“不可变意图”直接就通过类型表达出来了。这就像两个人合租你把手写便条贴在冰箱上“这里面东西不能动”比每次靠口头提醒靠谱得多。举个例子程序里定义一个菜单选项的列表# 这种“静态配置型”数据用元组更合适 menu_options (首页, 文章, 关于我) # 这种“动态运行型”数据用列表更合适 user_inputs [] user_inputs.append(a) user_inputs.append(b)区分标准也很简单这个集合本身在程序运行期间会不会增长、减少、排序会用列表不会用元组。这个习惯一旦养成你写的代码可读性会立刻上一个台阶。4.3 哈希能力能当字典key就是硬实力前面提到元组可哈希这个能力在工程里的价值被严重低估。最常见的场景是用元组做复杂键。比如游戏地图你要用格子的坐标来存NPC数据npc_map { (3, 5): 老村长, (8, 2): 杂货商, } pos (3, 5) print(npc_map.get(pos)) # 老村长如果把key换成列表解释器会直接抛TypeError: unhashable type: list。所谓不可哈希粗俗地理解就是“这东西不能做身份证号码”因为列表随时可能变变完身份就对不上了用它做key会导致整个字典的查找逻辑崩盘。元组的“身份”稳定才能充当这种关联关系中的key。还有一个实战技巧当你想对一个多参数函数做“结果缓存”时元组是天然缓存的钥匙。cache {} def expensive_compute(a, b, c): key (a, b, c) if key in cache: return cache[key] result a * 10000 b * 100 c # 假装是个很耗时计算 cache[key] result return result把函数的多个参数先打包成一个元组再作为缓存的key比拼接字符串key干净太多。这种模式在算法题、数据分析、递归计算里都很常见。5. 进阶玩法namedtuple 与元组的工程化应用5.1 namedtuple给元组里的每个位置起个名字元组虽然好但有个天生短板可读性差。user_info[0]和user_info[1]谁看得懂哪个是姓名哪个是年龄每次都要靠脑内记忆“索引0是姓名索引1是年龄”数据结构一复杂全靠猜。collections.namedtuple就是来解决这个问题的。它返回一个“元组的子类”既有元组的全部特性不可变、可解包、可哈希又给每个位置添加了字段名from collections import namedtuple # 第一个参数是类型名第二个参数是字段名列表 Student namedtuple(Student, [name, age, score]) s1 Student(王小明, 18, 92) print(s1.name) # 王小明 print(s1.age) # 18 print(s1.score) # 92 # 它本质上还是元组 print(isinstance(s1, tuple)) # True print(s1[0]) # 王小明 print(len(s1)) # 3字段名还能用字符串空格分隔着写效果一样Point namedtuple(Point, x y) p Point(100, 200) x, y p # 解包照常工作我用这个替代普通元组已经好几年了。凡是要在代码里多处访问元组元素的强烈建议用namedtuple它能直接把“索引魔法数”消灭掉。5.2 几十行数据处理的完整案例演示一个实际点的场景统计三个学生的成绩并求出最高分和最低分。from collections import namedtuple Student namedtuple(Student, [name, class_name, score]) students [ Student(王小明, 高三1班, 92), Student(李小红, 高三1班, 88), Student(张大力, 高三2班, 95), ] # 用字段名访问代码一目了然 best max(students, keylambda s: s.score) lowest min(students, keylambda s: s.score) print(f最高分: {best.name} {best.score}) # 张大力 95 print(f最低分: {lowest.name} {lowest.score}) # 李小红 88 # 排序也非常顺手 by_score sorted(students, keylambda s: s.score, reverseTrue) for s in by_score: print(s.class_name, s.name, s.score)如果用普通元组写max(students, keylambda s: s[2])虽然也能跑但每次都看到s[2]心智负担很重用字典写访问漂亮了但多了很多{...}和引号内存占用还高。namedtuple 在这类场景里是“轻量、可读、省内存”三者兼顾的解法。5.3 namedtuple和dataclass怎么选Python 3.7带来了dataclass很多人开始纠结到底用namedtuple还是dataclass我的取舍标准很简单。你需要“不可变数据 元组特性解包、哈希、索引”时无脑选namedtuple。它轻量、快、天生不可变。你需要给数据加默认值、类型注解、自定义方法、序列化逻辑时用dataclass更舒服。比如这个场景用 dataclass 更合适from dataclasses import dataclass dataclass(frozenTrue) class Student: name: str age: int 18 # 默认值 score: float 0.0 s Student(王小明) print(s.name, s.age) # 王小明 18注意frozenTrue这一步dataclass默认是可变对象你加了这个参数才能让它跟namedtuple一样不可变。所以如果你要的是“严格的不可变数据”可以两边都选但我个人经验是简单记录用namedtuple复杂领域模型用frozen dataclass。两头都通吃写出来的代码既顺手又不容易出歧义。6. 元组隐藏细节与新手坑盘点6.1 单元素元组的正确姿势再强调一次前面提过(42)是整数不是元组。这个坑在写return (1,)这种单值返回时特别容易爆炸。下面几个写法最好烂熟于心a (1) # int值为1 b (1,) # tuple值为(1,) c 1, # tuple值为(1,) d () # 空元组如果你要创建一个空的“数据记录”推荐用()如果你要创建一个单元素记录就老老实实写(value,)。宁可多打一个逗号也不要少打。6.2 元组的拼接、重复、比较与嵌套元组虽然不能修改但可以“生成新的元组”。拼接和重复都会返回一个全新的元组对象不会动原来的a (1, 2) b (3, 4) print(a b) # (1, 2, 3, 4) print(a * 3) # (1, 2, 1, 2, 1, 2) print(a) # (1, 2) 原元组毫发无损比较操作有点意思它按元素逐个从左到右比较类似字典序print((1, 2, 3) (1, 2, 4)) # True print((1, 2) (1, 2, 3)) # True短的先结束算小 print((2,) (1, 100, 1000)) # False第一个元素2 1直接出结果嵌套元组访问的时候注意逐层解引用matrix ((1, 2), (3, 4)) print(matrix[0][1]) # 2如果你要遍历一个深度不定的嵌套元组光靠普通for循环是不够的得递归def flatten(items): for item in items: if isinstance(item, tuple): yield from flatten(item) else: yield item data ((1, 2), (3, (4, 5))) print(list(flatten(data))) # [1, 2, 3, 4, 5]6.3 空元组的单例特性与常用陷阱CPython里有一个很隐蔽的优化所有空元组都指向同一个内存对象。也就是说a () b tuple() print(a is b) # True因为空元组不可变CPython直接搞了一个“单例空元组”怎么创建都是同一个对象。这本身不是坑但理解了它你就能明白创建一个空元组的开销几乎为零。反过来创建空列表每次都是新对象x [] y [] print(x is y) # False还有一个常被人忽视的坑函数默认参数如果用可变对象会踩雷def add_tag(item, tags[]): tags.append(item) return tags print(add_tag(a)) # [a] print(add_tag(b)) # [a, b] ← 第一次的tags被改了如果这个函数本来就不想共享累积数据应该写成def add_tag(item, tagsNone): if tags is None: tags [] tags.append(item) return tags如果你希望这个默认参数“只读”最稳的写法是用元组DEFAULT_TAGS (python, note) def add_tag(tagsDEFAULT_TAGS): print(tags)因为元组不可变谁敢在函数里偷偷tags.append()解释器直接报错把问题暴露在写代码阶段而不是运行到一半才出诡异数据。6.4 冷知识元组字面量在函数内会被编译成常量最后聊一个进阶冷知识。你把下面这个函数扔到Python里反汇编一下看字节码import dis def demo(): return (1, 2, 3) def demo2(): return [1, 2, 3] dis.dis(demo) dis.dis(demo2)demo函数的字节码会显示它直接LOAD_CONST一个已经编译好的常量元组而demo2需要先LOAD_CONST常量1、2、3再调用BUILD_LIST现场建列表。这就是为什么在函数里频繁创建固定元组字面量性能明显优于列表字面量的底层原因之一。不过说句公道话等你的数据量大到需要斤斤计较这一点性能时通常早就该上NumPy或数据库了。元组的性能优势更多是“顺手拿到的”选型的第一依据永远应该是语义而不是性能。把不会变的数据写成元组、会变的数据写成列表性能优势自然就跟着来了。最后再分享一点我自己的实践体会我平时凡是看到逻辑上不该被修改的固定结构——接口返回的配置项、一组坐标值、格式化的RGB颜色值、循环里用来解包的“记录”型数据——一律写元组。这不是为了较劲而是为了让代码类型本身变成文档看到元组就知道这里不允许追加、删除看到列表才去考虑迭代中添加数据的可能性。这个习惯帮我减少过太多看不懂的历史代码带来的“它是谁、它从哪来、它要去哪”的灵魂拷问。这一期关于元组的深度玩法就讲到这里下一期我们准备拿元组配合集合做点更好玩的评论区也欢迎分享一下你自己用元组用出来的奇技淫巧。