在Python快速入门系列里讲到元组这一课时我通常会特意多花一些时间。原因很简单几乎每个初学者都会问这不就是个不能改的列表吗而这个问题恰恰说明大家还没真正理解元组的设计价值。元组确实和列表长得很像但它在Python体系里的位置完全不是弱化版列表那么简单——它牵扯到数据安全、哈希机制、解包语法以及一批非常实在的编程习惯。这篇文章是系列第四篇专门把元组讲透。我会从它为什么存在开始一路讲到创建、操作、不可变性的边界再到命名元组和实际选型。适合正在入门Python的朋友也适合想回头补一补基础细节的老手。如果你现在写代码时几乎只用列表读完这篇之后我希望你能多一个习惯凡事多问一句这份数据到底该不该被修改。如果答案是不该那就让元组来替你守住这条线。1. 有列表就够了为什么还要学元组1.1 一次配置被改坏的事故让我重新认识不可变先说一段我早年的经历。某团队维护一套配置数据用列表存了一批固定的枚举状态。当时为了临时验证某个功能有同事往这个列表里append了一个测试值之后谁也没记得删。结果这个固定配置一路流到了下游判断逻辑里导致半个月后的一次线上小事故。排查到最后根因就是一句话列表在设计上本不该被改动但语言层面没有任何东西能拦住别人去改它。这正是元组存在的第一个理由。当你定义一个不该被修改的数据集合时元组会把不可修改直接写进语法。任何试图对它赋值、追加、删除的操作解释器当场抛TypeError而不是等到某个遥远的模块里出现诡异的副作用。用元组来表达这份数据是常量等于把约束从注释约定提升到了语言强制这种安心感在工程上非常值钱。1.2 元组能站稳脚跟的三个硬核理由除了防篡改元组还有两个经常被忽略、但分量很重的特点可哈希和更轻量。我把它们和列表放在一起对比如下对比维度元组列表可变性不可变元素引用不可修改可变可增删改能否作为字典键/集合元素可以元素全部可哈希时不可以存储开销更紧凑解释器有缓存优化更大预留扩容空间适用语义固定数据、返回值、复合键动态数据、需要频繁增删改动其中可哈希这一点很多人是第一次听说。简单解释哈希就是给数据算一个固定长度的指纹Python的字典键和集合元素都要求对象能稳定地算出这个指纹。因为元组的内容不可变所以它的哈希值稳定而列表内容能变指纹跟着变用来当键就会出大乱子所以Python干脆禁止列表参与哈希运算。这也是元组能当字典键、列表不行的根本原因。至于性能实测下来同样三个整数的容器元组占用的内存通常比列表更小验证方式很直观import sys print(sys.getsizeof((1, 2, 3))) # 典型输出 64字节 print(sys.getsizeof([1, 2, 3])) # 典型输出 80字节不同平台上数字会略有出入但元组更省这个结论在主流Python解释器上基本成立。原因也不复杂元组的大小在创建时就固定了不需要像列表那样预留额外的扩容空间。此外解释器还会对空元组这类小对象做复用最直接的验证是这一句 () is () True [] is [] False空元组永远只有一份实例而空列表每次都新建。单看一行表达式没什么感觉但累积到大规模项目里这些差异会变成可感知的内存和行为差异。2. 创建元组的正确姿势括号不是关键逗号才是2.1 三种常规创建方式最直观的创建方式是圆括号加逗号t1 (1, 2, 3) # 标准姿势 t2 () # 空元组 t3 (1,) # 单元素元组逗号不能省其中空元组可以用()直接表示算是特殊待遇单元素元组则必须写(1,)。这里的逗号是身份证少了它编译器会把括号理解成普通的运算符分组符号结果完全变味。2.2 坑一单元素元组的逗号丢了就变整数初学者最常见的问题就是写t (1)然后发现type(t)是int而不是tuple。原因很简单括号在这里只是数学里的优先级分组(1)本质上就是1。要让Python认定它是元组必须加一个结尾逗号 type((1)) class int type((1,)) class tuple这个点在学习时容易被忽略但在实际代码里很坑。比如你想构造一个只含一个元素的元组放进列表里漏了逗号整个逻辑都会悄悄变形而且不会报错。我自己在代码评审里见过不止一次这种问题每次都要提醒一句单元素元组逗号必须写。注意(1,)才是单元素元组(1)只是整数1。2.3 坑二逗号才是元组的灵魂比括号加逗号更本质的事实是在Python中逗号本身就是构造元组的运算符括号在很多场景下只是可选的包装。你可以完全不要括号 t 1, 2, 3 type(t) class tuple甚至a 1,也是合法的单元素元组。但有个地方特别容易混淆函数调用里的逗号是参数分隔符print(1, 2, 3)打印的是三个参数而不是元组。所以别想着靠去掉括号在任何地方都能造出元组得先分清楚语境。由于逗号是运算符它还参与运算符优先级。比如1, 2 * 3得到的是(1, 6)因为乘法先于逗号执行。这种细节平时用得不多但理解了它你就能判断什么时候括号必须写什么时候不写也没关系。2.4 坑三tuple() 只收可迭代对象第三种创建方式是调用构造函数tuple()。它接受任何可迭代对象包括把列表转成元组、把字符串拆成字符元组 tuple([1, 2, 3]) (1, 2, 3) tuple(abc) (a, b, c) tuple() ()但要特别注意tuple(5)会报TypeError: int object is not iterable。整数不是可迭代对象没法直接转成元组。如果你想把单一整数放进元组正确写法是(5,)而不是tuple(5)。这个坑我见过不止一次它通常出现在把某个值从普通变量改成元组的匆忙重构里值得单独记一笔。3. 元组的基本功索引、切片、拼接与成员判断3.1 索引和切片和列表高度一致元组的下标访问和列表完全一样支持正索引、负索引和步长切片t (10, 20, 30, 40, 50) print(t[0]) # 10 print(t[-1]) # 50负索引从末尾数 print(t[1:4]) # (20, 30, 40)切片结果仍然是元组 print(t[::-1]) # (50, 40, 30, 20, 10)步长为-1实现倒序需要记住的一点是对元组切片返回的一定是新元组而不是列表。Python里切片操作返回与原容器同类型这个规律在元组这里体现得清清楚楚。如果你想要列表就显式写成list(t[1:4])别指望切片自动给你转类型。3.2 拼接、重复与成员判断元组支持拼接和*重复这跟字符串的行为很像t (1, 2, 3) print(t (4, 5)) # (1, 2, 3, 4, 5) print(t * 3) # (1, 2, 3, 1, 2, 3, 1, 2, 3)成员判断用in和not in长度用len()print(2 in t) # True print(9 not in t) # True print(len(t)) # 3这里有一个实操提醒元组的每次都会生成一个新对象。如果你在循环里反复做t t (x,)一旦数据量变大效率会明显下降。正确的做法是先用列表收集最后一次性tuple(lst)转换。我在做数据清洗时经常用这个方式既保留了元组的不变性又避免了重复创建对象的开销。3.3 为什么元组只有count和index两个方法打开IDE的自动补全你会发现元组的方法列表短得可怜只有count()和index()。原因其实很直白——它是不可变对象所以append()、remove()、extend()、sort()这些修改自身的方法统统不存在而count()统计某个值出现的次数、index()查找某个值的下标都是只读操作和不可变特性不冲突。t (1, 2, 3, 2) print(t.count(2)) # 2 print(t.index(3)) # 2返回第一次出现的下标顺带一提index()还支持起始和结束参数可以在指定范围内查找。两个方法虽然少但配合in、len()、max()、min()这些内置函数日常查询需求完全够用。3.4 列表和元组的互转list(t)可以把元组转回列表tuple(lst)可以把列表转成元组。这个互转非常常用比如你从某个接口拿到一批记录是元组结构需要临时排序可以先转成列表操作完再转回来不会污染原始数据lst list((3, 1, 2)) lst.sort() print(tuple(lst)) # (1, 2, 3)元组本身没有sort()方法转成列表再排序是标准做法。这个互转的代价很小但能让你灵活地在可变和不可变两种模式之间切换。4. 不可变性的真相冻得住引用冻不住内容4.1 不可变的确切含义这是元组这一课里最值得展开的部分。很多教材只说元组不可变但没解释到底哪里不可变。准确地说元组的不可变指的是每个位置上保存的引用不能被重新绑定而不是说这些引用指向的对象本身不能变。打个比方元组就像一个固定座位的寄存柜每个格子贴上标签、存放一个箱子。说它不可变是指你不能把格子里的箱子替换成另一个箱子也不能把标签换掉。但如果你存进去的是一个本身可以打开的收纳箱那你在格子里打开箱子、往里面加东西是完全允许的。4.2 元组里塞一个列表合法但危险最经典的演示就是元组里放一个列表t (1, 2, [3, 4]) t[2].append(5) print(t) # (1, 2, [3, 4, 5])这行能成功执行 t[2] [10] # TypeError: tuple object does not support item assignmentt[2].append(5)是修改列表内容不涉及重新绑定t[2]这个引用所以合法t[2] [10]是想让t[2]指向一个新列表这在元组看来就是换格子里的箱子直接报错。理解这一层后你就不会再被元组不可变这句话误导也能解释为什么下面的代码行为看起来那么矛盾。4.3 连锁反应含可变元素的元组无法哈希这个半冻结的细节会引发一个很实际的连锁反应元组的哈希值能否计算取决于它内部的所有元素是否都可哈希。列表不可哈希所以一个含列表的元组无法计算哈希也就不能当字典键、不能放进集合 hash((1, 2, 3)) # 正常得到一个整数具体值每次运行可能不同 -8309375262264248499 hash((1, [2, 3])) # 立刻抛错 Traceback (most recent call last): ... TypeError: unhashable type: list这其实是一种刻意设计的安全机制。如果元组里装了可变元素哈希值会随内容变化而失效用它做字典键就会破坏查找逻辑。所以Python干脆在计算哈希的时候就把你拦住宁可报错也不给隐患留机会。想构造真正意义上完全不可变的复合数据原则很简单元组的每个元素本身也得是不可变对象。整数、字符串、浮点数、另一个元组都没问题列表、字典、集合这类可变容器则不行。如果确实需要递归不可变的集合可以考虑frozenset或自定义不可变类。提示判断一个元组能不能哈希先看它里面装的每个元素能不能哈希。有一个可变元素整个元组就进不了字典键的世界。5. 解包与多返回值元组最值得炫耀的语法糖5.1 平行赋值与交换变量的秘密元组最让人舒服的语法必然是解包unpacking。所谓解包就是把元组里的元素按位置分别赋给一组变量a, b 1, 2 print(a, b) # 1 2这里右边的1, 2其实先被构造成元组(1, 2)再做解包赋值。理解了这一层你就能明白为什么Python里交换两个变量不需要临时变量a, b b, a等号右边的b, a先包装成元组(b, a)再依次解开赋给a和b。整个过程不会出现右边还没算完、左边就被覆盖的经典问题。我在教别人的时候用这一行代码讲表达式求值顺序比背十条规则都管用。5.2 函数的多返回值省掉输出参数解包最常见的应用场景是函数返回多个值。很多语言要么返回一个对象、要么用输出参数Python则直接返回元组def divide(a, b): return a // b, a % b q, r divide(10, 3) print(q, r) # 3 1return a // b, a % b看起来返回了两个值本质是构造并返回一个元组。调用端用解包接住代码简洁得不像话。这也是元组最值得炫耀的语法糖——它让函数返回多个值成为真正的一等公民体验。5.3 带星号的解包应付不定长数据如果元组的长度不固定可以用星号表达式把多余部分收进一个列表first, *middle, last (1, 2, 3, 4, 5) print(first) # 1 print(middle) # [2, 3, 4] print(last) # 5注意这里星号变量收集到的是列表不是元组。这个特性在解析不定长记录时非常实用比如从配置元组里取首尾元素、把中间参数整体传给另一个函数。我自己在写日志解析、命令行参数处理时经常用到。5.4 嵌套解包与参数展开元组支持嵌套解包只要结构对齐一次就能拆到底((x, y), z) ((1, 2), 3) print(x, y, z) # 1 2 3还有一个方向相反的技巧调用函数时把元组用*展开成位置参数def add(a, b, c): return a b c params (10, 20, 30) print(add(*params)) # 60这两招在写通用函数、做参数转发时非常省事。解包的规则总结起来就是一句话等号两边结构对齐左边的每个名字都能找到右边的对应值。这个对称性正是Python元组设计得优雅的地方。6. 进阶与选型命名元组、字典键与我的使用习惯6.1 namedtuple让元组不再无名无姓普通元组的缺点也很明显访问元素靠下标t[0]写多了没人记得0到底是什么。解决这个问题标准库提供了一个现成工具namedtuplefrom collections import namedtuple Point namedtuple(Point, [x, y]) p Point(3, 4) print(p.x, p.y) # 3 4 print(p[0], p[1]) # 3 4下标访问依然保留命名元组同时具备两个优点它像元组一样不可变、可以解包、可以哈希又像一个小对象一样有字段名代码可读性大幅提升。适合那些字段不多、数量很大的轻量数据结构——比如经纬度坐标、颜色RGB、表格里的一行记录。比起动不动就定义一个有零个方法的类命名元组轻巧得多。6.2 元组当字典键比想象中更常用元组可以哈希所以它天然适合做复合键。最典型的例子是二维坐标到值的映射coords { (10, 20): 站点A, (30, 40): 站点B, } print(coords[(10, 20)]) # 站点A把(x, y)当键省去了把两个数拼成字符串再当键的丑陋做法也不会出现分隔符冲突问题。同理如果你有一批状态类型的组合需要做去重统计用元组放进集合也是标准解法。我处理过不少两张表按多个字段关联的需求元组键在这里几乎是唯一直觉又可靠的方案。6.3 元组 vs 列表的选型清单写代码时如何快速决策我习惯按下面这张表判断场景推荐容器理由数据需要增删改、排序、就地反转列表可变性正是需求本身固定配置、常量集合、枚举状态元组语法层面阻止误改需要作为字典键或集合元素元组可哈希是硬前提函数返回多个值元组解包语法天然搭配字段少但语义明确的数据记录命名元组下标和字段名都能用数据量大且只读元组内存更省、无扩容开销需要说明的是我不主张元组一定比列表好的绝对论。选列表还是选元组本质是回答一个问题这份数据在生命周期里到底会不会变会变别为难自己用列表不会变用元组把约束写死让未来的维护者——包括自己——少踩坑。6.4 一个自测题和我的工程习惯最后说说我自己的使用习惯。第一凡是函数返回固定数量的多个值默认用元组如果这些值语义复杂、容易混淆就升级成命名元组。第二凡是定义全局常量集合优先写元组因为任何误改都会立刻报错暴露。第三凡是遇到既要下标遍历、又想要字段名可读的记录型数据第一个想到的是命名元组而不是再定义一个类。判断自己是不是真的理解元组我推荐一个简单的自测方法你能不能一口气说清楚元组为什么可以当字典键而列表不行并且解释t (1, 2, [3])这种结构为什么不能哈希。如果都能答上来这关就算过了。根据我个人经验把元组用顺手的开发者写出来的代码在数据边界这件事上通常都更干净——因为它逼着你想清楚每份数据到底该不该被修改。元组很小但在Python里它绝不是可有可无的角色。 
长河君 · 2026/10/15 10:48:40 · 阅读 1.2k Python元组完全指南：从不可变到解包，理解元组的真正价值
在Python快速入门系列里讲到元组这一课时我通常会特意多花一些时间。原因很简单几乎每个初学者都会问这不就是个不能改的列表吗而这个问题恰恰说明大家还没真正理解元组的设计价值。元组确实和列表长得很像但它在Python体系里的位置完全不是弱化版列表那么简单——它牵扯到数据安全、哈希机制、解包语法以及一批非常实在的编程习惯。这篇文章是系列第四篇专门把元组讲透。我会从它为什么存在开始一路讲到创建、操作、不可变性的边界再到命名元组和实际选型。适合正在入门Python的朋友也适合想回头补一补基础细节的老手。如果你现在写代码时几乎只用列表读完这篇之后我希望你能多一个习惯凡事多问一句这份数据到底该不该被修改。如果答案是不该那就让元组来替你守住这条线。1. 有列表就够了为什么还要学元组1.1 一次配置被改坏的事故让我重新认识不可变先说一段我早年的经历。某团队维护一套配置数据用列表存了一批固定的枚举状态。当时为了临时验证某个功能有同事往这个列表里append了一个测试值之后谁也没记得删。结果这个固定配置一路流到了下游判断逻辑里导致半个月后的一次线上小事故。排查到最后根因就是一句话列表在设计上本不该被改动但语言层面没有任何东西能拦住别人去改它。这正是元组存在的第一个理由。当你定义一个不该被修改的数据集合时元组会把不可修改直接写进语法。任何试图对它赋值、追加、删除的操作解释器当场抛TypeError而不是等到某个遥远的模块里出现诡异的副作用。用元组来表达这份数据是常量等于把约束从注释约定提升到了语言强制这种安心感在工程上非常值钱。1.2 元组能站稳脚跟的三个硬核理由除了防篡改元组还有两个经常被忽略、但分量很重的特点可哈希和更轻量。我把它们和列表放在一起对比如下对比维度元组列表可变性不可变元素引用不可修改可变可增删改能否作为字典键/集合元素可以元素全部可哈希时不可以存储开销更紧凑解释器有缓存优化更大预留扩容空间适用语义固定数据、返回值、复合键动态数据、需要频繁增删改动其中可哈希这一点很多人是第一次听说。简单解释哈希就是给数据算一个固定长度的指纹Python的字典键和集合元素都要求对象能稳定地算出这个指纹。因为元组的内容不可变所以它的哈希值稳定而列表内容能变指纹跟着变用来当键就会出大乱子所以Python干脆禁止列表参与哈希运算。这也是元组能当字典键、列表不行的根本原因。至于性能实测下来同样三个整数的容器元组占用的内存通常比列表更小验证方式很直观import sys print(sys.getsizeof((1, 2, 3))) # 典型输出 64字节 print(sys.getsizeof([1, 2, 3])) # 典型输出 80字节不同平台上数字会略有出入但元组更省这个结论在主流Python解释器上基本成立。原因也不复杂元组的大小在创建时就固定了不需要像列表那样预留额外的扩容空间。此外解释器还会对空元组这类小对象做复用最直接的验证是这一句 () is () True [] is [] False空元组永远只有一份实例而空列表每次都新建。单看一行表达式没什么感觉但累积到大规模项目里这些差异会变成可感知的内存和行为差异。2. 创建元组的正确姿势括号不是关键逗号才是2.1 三种常规创建方式最直观的创建方式是圆括号加逗号t1 (1, 2, 3) # 标准姿势 t2 () # 空元组 t3 (1,) # 单元素元组逗号不能省其中空元组可以用()直接表示算是特殊待遇单元素元组则必须写(1,)。这里的逗号是身份证少了它编译器会把括号理解成普通的运算符分组符号结果完全变味。2.2 坑一单元素元组的逗号丢了就变整数初学者最常见的问题就是写t (1)然后发现type(t)是int而不是tuple。原因很简单括号在这里只是数学里的优先级分组(1)本质上就是1。要让Python认定它是元组必须加一个结尾逗号 type((1)) class int type((1,)) class tuple这个点在学习时容易被忽略但在实际代码里很坑。比如你想构造一个只含一个元素的元组放进列表里漏了逗号整个逻辑都会悄悄变形而且不会报错。我自己在代码评审里见过不止一次这种问题每次都要提醒一句单元素元组逗号必须写。注意(1,)才是单元素元组(1)只是整数1。2.3 坑二逗号才是元组的灵魂比括号加逗号更本质的事实是在Python中逗号本身就是构造元组的运算符括号在很多场景下只是可选的包装。你可以完全不要括号 t 1, 2, 3 type(t) class tuple甚至a 1,也是合法的单元素元组。但有个地方特别容易混淆函数调用里的逗号是参数分隔符print(1, 2, 3)打印的是三个参数而不是元组。所以别想着靠去掉括号在任何地方都能造出元组得先分清楚语境。由于逗号是运算符它还参与运算符优先级。比如1, 2 * 3得到的是(1, 6)因为乘法先于逗号执行。这种细节平时用得不多但理解了它你就能判断什么时候括号必须写什么时候不写也没关系。2.4 坑三tuple() 只收可迭代对象第三种创建方式是调用构造函数tuple()。它接受任何可迭代对象包括把列表转成元组、把字符串拆成字符元组 tuple([1, 2, 3]) (1, 2, 3) tuple(abc) (a, b, c) tuple() ()但要特别注意tuple(5)会报TypeError: int object is not iterable。整数不是可迭代对象没法直接转成元组。如果你想把单一整数放进元组正确写法是(5,)而不是tuple(5)。这个坑我见过不止一次它通常出现在把某个值从普通变量改成元组的匆忙重构里值得单独记一笔。3. 元组的基本功索引、切片、拼接与成员判断3.1 索引和切片和列表高度一致元组的下标访问和列表完全一样支持正索引、负索引和步长切片t (10, 20, 30, 40, 50) print(t[0]) # 10 print(t[-1]) # 50负索引从末尾数 print(t[1:4]) # (20, 30, 40)切片结果仍然是元组 print(t[::-1]) # (50, 40, 30, 20, 10)步长为-1实现倒序需要记住的一点是对元组切片返回的一定是新元组而不是列表。Python里切片操作返回与原容器同类型这个规律在元组这里体现得清清楚楚。如果你想要列表就显式写成list(t[1:4])别指望切片自动给你转类型。3.2 拼接、重复与成员判断元组支持拼接和*重复这跟字符串的行为很像t (1, 2, 3) print(t (4, 5)) # (1, 2, 3, 4, 5) print(t * 3) # (1, 2, 3, 1, 2, 3, 1, 2, 3)成员判断用in和not in长度用len()print(2 in t) # True print(9 not in t) # True print(len(t)) # 3这里有一个实操提醒元组的每次都会生成一个新对象。如果你在循环里反复做t t (x,)一旦数据量变大效率会明显下降。正确的做法是先用列表收集最后一次性tuple(lst)转换。我在做数据清洗时经常用这个方式既保留了元组的不变性又避免了重复创建对象的开销。3.3 为什么元组只有count和index两个方法打开IDE的自动补全你会发现元组的方法列表短得可怜只有count()和index()。原因其实很直白——它是不可变对象所以append()、remove()、extend()、sort()这些修改自身的方法统统不存在而count()统计某个值出现的次数、index()查找某个值的下标都是只读操作和不可变特性不冲突。t (1, 2, 3, 2) print(t.count(2)) # 2 print(t.index(3)) # 2返回第一次出现的下标顺带一提index()还支持起始和结束参数可以在指定范围内查找。两个方法虽然少但配合in、len()、max()、min()这些内置函数日常查询需求完全够用。3.4 列表和元组的互转list(t)可以把元组转回列表tuple(lst)可以把列表转成元组。这个互转非常常用比如你从某个接口拿到一批记录是元组结构需要临时排序可以先转成列表操作完再转回来不会污染原始数据lst list((3, 1, 2)) lst.sort() print(tuple(lst)) # (1, 2, 3)元组本身没有sort()方法转成列表再排序是标准做法。这个互转的代价很小但能让你灵活地在可变和不可变两种模式之间切换。4. 不可变性的真相冻得住引用冻不住内容4.1 不可变的确切含义这是元组这一课里最值得展开的部分。很多教材只说元组不可变但没解释到底哪里不可变。准确地说元组的不可变指的是每个位置上保存的引用不能被重新绑定而不是说这些引用指向的对象本身不能变。打个比方元组就像一个固定座位的寄存柜每个格子贴上标签、存放一个箱子。说它不可变是指你不能把格子里的箱子替换成另一个箱子也不能把标签换掉。但如果你存进去的是一个本身可以打开的收纳箱那你在格子里打开箱子、往里面加东西是完全允许的。4.2 元组里塞一个列表合法但危险最经典的演示就是元组里放一个列表t (1, 2, [3, 4]) t[2].append(5) print(t) # (1, 2, [3, 4, 5])这行能成功执行 t[2] [10] # TypeError: tuple object does not support item assignmentt[2].append(5)是修改列表内容不涉及重新绑定t[2]这个引用所以合法t[2] [10]是想让t[2]指向一个新列表这在元组看来就是换格子里的箱子直接报错。理解这一层后你就不会再被元组不可变这句话误导也能解释为什么下面的代码行为看起来那么矛盾。4.3 连锁反应含可变元素的元组无法哈希这个半冻结的细节会引发一个很实际的连锁反应元组的哈希值能否计算取决于它内部的所有元素是否都可哈希。列表不可哈希所以一个含列表的元组无法计算哈希也就不能当字典键、不能放进集合 hash((1, 2, 3)) # 正常得到一个整数具体值每次运行可能不同 -8309375262264248499 hash((1, [2, 3])) # 立刻抛错 Traceback (most recent call last): ... TypeError: unhashable type: list这其实是一种刻意设计的安全机制。如果元组里装了可变元素哈希值会随内容变化而失效用它做字典键就会破坏查找逻辑。所以Python干脆在计算哈希的时候就把你拦住宁可报错也不给隐患留机会。想构造真正意义上完全不可变的复合数据原则很简单元组的每个元素本身也得是不可变对象。整数、字符串、浮点数、另一个元组都没问题列表、字典、集合这类可变容器则不行。如果确实需要递归不可变的集合可以考虑frozenset或自定义不可变类。提示判断一个元组能不能哈希先看它里面装的每个元素能不能哈希。有一个可变元素整个元组就进不了字典键的世界。5. 解包与多返回值元组最值得炫耀的语法糖5.1 平行赋值与交换变量的秘密元组最让人舒服的语法必然是解包unpacking。所谓解包就是把元组里的元素按位置分别赋给一组变量a, b 1, 2 print(a, b) # 1 2这里右边的1, 2其实先被构造成元组(1, 2)再做解包赋值。理解了这一层你就能明白为什么Python里交换两个变量不需要临时变量a, b b, a等号右边的b, a先包装成元组(b, a)再依次解开赋给a和b。整个过程不会出现右边还没算完、左边就被覆盖的经典问题。我在教别人的时候用这一行代码讲表达式求值顺序比背十条规则都管用。5.2 函数的多返回值省掉输出参数解包最常见的应用场景是函数返回多个值。很多语言要么返回一个对象、要么用输出参数Python则直接返回元组def divide(a, b): return a // b, a % b q, r divide(10, 3) print(q, r) # 3 1return a // b, a % b看起来返回了两个值本质是构造并返回一个元组。调用端用解包接住代码简洁得不像话。这也是元组最值得炫耀的语法糖——它让函数返回多个值成为真正的一等公民体验。5.3 带星号的解包应付不定长数据如果元组的长度不固定可以用星号表达式把多余部分收进一个列表first, *middle, last (1, 2, 3, 4, 5) print(first) # 1 print(middle) # [2, 3, 4] print(last) # 5注意这里星号变量收集到的是列表不是元组。这个特性在解析不定长记录时非常实用比如从配置元组里取首尾元素、把中间参数整体传给另一个函数。我自己在写日志解析、命令行参数处理时经常用到。5.4 嵌套解包与参数展开元组支持嵌套解包只要结构对齐一次就能拆到底((x, y), z) ((1, 2), 3) print(x, y, z) # 1 2 3还有一个方向相反的技巧调用函数时把元组用*展开成位置参数def add(a, b, c): return a b c params (10, 20, 30) print(add(*params)) # 60这两招在写通用函数、做参数转发时非常省事。解包的规则总结起来就是一句话等号两边结构对齐左边的每个名字都能找到右边的对应值。这个对称性正是Python元组设计得优雅的地方。6. 进阶与选型命名元组、字典键与我的使用习惯6.1 namedtuple让元组不再无名无姓普通元组的缺点也很明显访问元素靠下标t[0]写多了没人记得0到底是什么。解决这个问题标准库提供了一个现成工具namedtuplefrom collections import namedtuple Point namedtuple(Point, [x, y]) p Point(3, 4) print(p.x, p.y) # 3 4 print(p[0], p[1]) # 3 4下标访问依然保留命名元组同时具备两个优点它像元组一样不可变、可以解包、可以哈希又像一个小对象一样有字段名代码可读性大幅提升。适合那些字段不多、数量很大的轻量数据结构——比如经纬度坐标、颜色RGB、表格里的一行记录。比起动不动就定义一个有零个方法的类命名元组轻巧得多。6.2 元组当字典键比想象中更常用元组可以哈希所以它天然适合做复合键。最典型的例子是二维坐标到值的映射coords { (10, 20): 站点A, (30, 40): 站点B, } print(coords[(10, 20)]) # 站点A把(x, y)当键省去了把两个数拼成字符串再当键的丑陋做法也不会出现分隔符冲突问题。同理如果你有一批状态类型的组合需要做去重统计用元组放进集合也是标准解法。我处理过不少两张表按多个字段关联的需求元组键在这里几乎是唯一直觉又可靠的方案。6.3 元组 vs 列表的选型清单写代码时如何快速决策我习惯按下面这张表判断场景推荐容器理由数据需要增删改、排序、就地反转列表可变性正是需求本身固定配置、常量集合、枚举状态元组语法层面阻止误改需要作为字典键或集合元素元组可哈希是硬前提函数返回多个值元组解包语法天然搭配字段少但语义明确的数据记录命名元组下标和字段名都能用数据量大且只读元组内存更省、无扩容开销需要说明的是我不主张元组一定比列表好的绝对论。选列表还是选元组本质是回答一个问题这份数据在生命周期里到底会不会变会变别为难自己用列表不会变用元组把约束写死让未来的维护者——包括自己——少踩坑。6.4 一个自测题和我的工程习惯最后说说我自己的使用习惯。第一凡是函数返回固定数量的多个值默认用元组如果这些值语义复杂、容易混淆就升级成命名元组。第二凡是定义全局常量集合优先写元组因为任何误改都会立刻报错暴露。第三凡是遇到既要下标遍历、又想要字段名可读的记录型数据第一个想到的是命名元组而不是再定义一个类。判断自己是不是真的理解元组我推荐一个简单的自测方法你能不能一口气说清楚元组为什么可以当字典键而列表不行并且解释t (1, 2, [3])这种结构为什么不能哈希。如果都能答上来这关就算过了。根据我个人经验把元组用顺手的开发者写出来的代码在数据边界这件事上通常都更干净——因为它逼着你想清楚每份数据到底该不该被修改。元组很小但在Python里它绝不是可有可无的角色。