Python数据结构精讲：列表、元组、集合、字典与拆包推导式

列表、元组、集合、字典，这四个容器类型在Python里几乎天天见，拆包和推导式又是写出简洁代码的必经之路。很多人学到这容易懵，不是因为单个知识点太难，而是不知道每种结构到底该在什么场景用、底层是怎么跑的。这堂课我按自己的理解重新组织了一遍，把每一种数据结构的特性、适用场景、坑点一次性讲透，最后再把拆包和推导式这两个高频技巧用实例拆开来看。无论你是刚入门想打牢基础，还是写了一阵子代码想补补短板，这份内容都值得你跟着敲一遍。

1. 四种数据结构的整体对比与设计思路

1.1 先搞清楚它们各自是什么角色

初学Python的时候，不少人会有这种感觉：同样的数据，好像用哪种结构装都行？比如一个学生名单，用列表能装，用元组也能装，用集合好像也行，甚至用字典也能硬塞进去。确实，Python的容器类型之间边界并不像某些语言那么死板，但设计它们的时候，每一种都有自己的明确倾向。

我习惯用生活场景来理解：

• 列表就像超市购物车。你往里扔东西，它保持你扔进去的顺序，你可以把某个东西抽出来看看，也可以把新东西插到任意位置，甚至可以推着车来回逛——它允许你随时改动车里的一切。
• 元组更像是一个已经封装好的坐标点。比如地图上的经纬度(116.40, 39.90)，一旦确定就不会改。它的核心意义是不可变，用来表示那些“本质上就不该变”的数据。
• 字典就是一本通讯录。你按照名字去找电话号码，而不是按照第几个来翻。它解决的问题是“按键查找”，而不是“按顺序遍历”。
• 集合则像是一个空房间里的打卡名单。每个人来了就报个名字，有重复的自动去掉，最后你只关心谁来过，不关心他第几个来的。

这四种结构不是可以随意替换的，它们各自解决了不同类型的问题。如果你在写代码时拿不准该用哪种，先问自己三个问题：数据需要保持顺序吗？需要修改吗？需要快速查找吗？三个问题一问，答案基本就出来了。

1.2 列表与元组：可变与不可变的选择逻辑

很多人在写代码的时候会忽略元组，觉得它就是个不可变的列表，没啥用。这个想法我在早期也犯过。直到有一次写一个配置模块，把数据库连接参数定义成列表，结果代码里不知道哪一处的逻辑意外修改了它，排查了半天才发现问题是数据被改了。从那以后，凡是语义上不该变化的数据，我统一用元组，让Python在运行时报错来保护我。

元组和列表的性能差异并不大，真正核心的区别在于“可哈希性”。因为元组不可变，它可以被当作字典的键，也可以放进集合里，而列表不行。所以当你需要一个复合键的时候，比如用(x, y)坐标作为字典键，用元组几乎是唯一方便的选择。

列表的适用场景则反过来：你明确知道这批数据会增删改，或者需要调用append、insert、pop这类方法时，直接选列表。用列表模拟栈、队列、待办列表、搜索结果集，都是常规操作。

1.3 字典与集合：哈希表的两兄弟

字典和集合在Python内部都是基于哈希表实现的，所以它们有一个共同的特点：查找速度极快。无论容器里有一百个元素还是一万个元素，查找某个键的时间都接近常数。这个特性和列表完全不同——列表查找一个元素，最坏情况下要遍历整个列表。

也正因为底层是哈希表，字典的键和集合的元素都必须是可哈希的，也就是不可变类型。整数、浮点数、字符串、元组都可以，列表和字典本身不行。这个限制是很多初学者容易踩坑的地方，也是最值得深入理解的地方：当你试图把一个列表作为字典的键时，Python直接抛TypeError，不是故意为难你，而是哈希表压根无法处理一个“内容可以变化”的条目。

网上流传的“wifi密码字典”这类文件，本质上就是把大量候选密码存成一个列表或字典，拿来做碰撞测试。用Python处理这种纯文本字典文件时，集合的去重能力就很有用——几万条密码里可能有大量重复，读进集合可以瞬间去重，再转成列表保存，效率提升非常明显。你甚至可以用一行推导式完成读取、去重、排序三个操作。这就是我们后面要讲的推导式和集合配合的典型场景。

2. 核心操作细节与实操要点

2.1 列表的常用操作与切片技巧

列表的创建方式非常灵活，字面量、list()构造函数、字符串拆分、range生成都可以。比如：

fruits = ["apple", "banana", "cherry"] numbers = list(range(1, 6)) chars = list("hello")

append和extend的区别是高频考点。append把整个参数作为一个元素追加进去，extend则把参数中的元素逐个追加。如果把一个列表extend进另一个列表，结果会直接展开；如果用append，列表会嵌套进去。这个差异在实操中经常引发意外，尤其是处理嵌套列表的时候。

插入和删除也有讲究：

nums = [1, 2, 3, 4, 5] nums.insert(0, 0) # 头部插入0，结果为 [0, 1, 2, 3, 4, 5] nums.pop() # 删除并返回最后一个元素5 nums.pop(0) # 删除并返回第一个元素0 nums.remove(3) # 按值删除第一个出现的3 del nums[0] # 按下标删除

这里有个重要的经验：remove按值删除元素的时间复杂度是O(n)，因为需要先遍历找到目标；pop和del按下标删除的时间复杂度是O(1)。如果你的程序频繁删除大量元素，考虑用“标记-过滤”的方式重新生成列表，而不是在一个循环里反复remove，不然数据量大时会慢得怀疑人生。

切片是列表里最常用也最容易出错的点。基本语法是list[start:stop:step]，左闭右开。很多人记不清stop到底取不取，其实记住一个口诀就行：end不包含，“取到end前一位”。几个关键示例：

nums = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] nums[2:5] # [2, 3, 4]，注意不包含5 nums[:3] # [0, 1, 2]，从头开始 nums[5:] # [5, 6, 7, 8, 9]，到末尾结束 nums[::2] # [0, 2, 4, 6, 8]，每隔一个取一个 nums[::-1] # [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]，这一步直接实现列表反转

切片操作返回的是一个新的列表，这在需要复制副本的场景中非常好用。但要注意，这个复制是“浅拷贝”——如果列表里的元素是可变对象（比如子列表），新列表里的子列表和原列表共享同一份引用。后面第5章会专门讲这个坑。

2.2 字典的增删改查与合并技巧

字典的定义方式很多，最常用的还是直接量：

user = {"name": "张三", "age": 25, "city": "北京"}

访问字典里的值，新手最容易犯的错误是直接用user["name"]，当键不存在时直接抛KeyError。更稳妥的写法是用get方法，它允许你指定默认值：

height = user.get("height", 170)

这种写法在爬虫处理JSON数据时特别有用。你拿到一个嵌套很深的字典，某些字段可能缺失，用get层层取值可以避免写满屏幕的try-except。

字典的新增和修改是同一个语法：user["email"] = "zhangsan@example.com"。键不存在就新增，存在就更新。删除用pop(key, default)可以避免KeyError，或者del user["key"]。

遍历字典有几种方式，按需选择：

for key in user: # 遍历键 for value in user.values(): # 遍历值 for key, value in user.items(): # 同时遍历键和值

items()返回的就是一组组(key, value)元组，这自然引出拆包的应用——在循环里直接写成for k, v in user.items()，其实就是每次迭代都对一个二元组做拆包。很多教程把拆包单独讲，却没指出这一层关系。理解了这点，你再看循环遍历字典的代码会通透很多。

字典合并也是一道经典题。Python 3.9之前，通过{**dict1, **dict2}或者dict1.update(dict2)合并，后者会原地修改dict1。Python 3.9之后直接支持dict1 | dict2，返回一个新的合并结果，后者覆盖前者相同键的值：

base_info = {"name": "李四", "age": 30} extra_info = {"city": "上海", "age": 31} merged = base_info | extra_info # merged = {"name": "李四", "age": 31, "city": "上海"}

这种写法简洁且语义清晰，兼容Python 3.9以上环境时建议优先使用。

2.3 集合的去重原理与常用运算

集合的头号用途就是去重。处理一个包含大量重复元素的列表，一行代码搞定：

data = [1, 2, 2, 3, 3, 3, 4] unique_data = list(set(data)) # unique_data = [1, 2, 3, 4]，注意顺序不保证

需要注意的是，set(data)不会保持原来的顺序。如果你既要去重又要保持顺序，就得稍微多写几行：

seen = set() result = [] for item in data: if item not in seen: seen.add(item) result.append(item)

这个写法利用了集合的快速查找特性，同时用列表保持原有顺序。我在处理日志去重、用户ID去重这类任务时经常用到。

集合还有几个非常有用的集合运算。交集用&，并集用|，差集用-，对称差集用^。举个实战场景：两个爬虫脚本分别抓取了一组URL，想知道哪些URL两边都抓到了，直接url_set1 & url_set2，一行代码搞定，比自己写循环判断快得多也清晰得多。

集合的底层是哈希表，和字典的键一样，元素必须是可哈希的。所以集合里可以放字符串、数字、元组，但不能放列表和字典。这个限制在实操中经常被忽略，比如你想把一个列表去重时，如果元素本身是列表（比如二维坐标点），直接set会报错。解决办法是把列表转成元组再放入集合：

points = [[1, 2], [1, 2], [3, 4]] unique_points = set(map(tuple, points)) # unique_points = {(1, 2), (3, 4)}

2.4 元组的不可变性与单元素陷阱

元组的不可变性需要重点理解。很多人以为元组完全不能变，其实它的不可变指的是“元组本身的结构不可变”，包括元素的个数、每个元素指向的对象。如果元组里放了一个列表，这个列表的内容是可以改变的：

t = (1, [2, 3], 4) t[1].append(99) # t = (1, [2, 3, 99], 4)

这在业务上偶尔会造成困惑，但记住一点就够：元组保证的是“引用不变”，不保证“对象内部状态不变”。

创建单元素元组有个著名的坑：t = (1)得到的是整数1，而不是元组。正确写法是加一个逗号：t = (1,)。这个细节让不少新手调试了半天。

namedtuple是元组的增强版，它给元组的每个位置起了一个名字，代码可读性提升不少：

from collections import namedtuple Point = namedtuple("Point", ["x", "y"]) p = Point(10, 20) print(p.x, p.y) # 10 20

如果你需要在固定结构的数据上提升可读性，又不想引入完整定义一个类，namedtuple是一个性价比极高的选择。

3. 拆包：让代码从冗长变优雅

3.1 基础拆包与多变量赋值

拆包（unpacking）的本质，是把一个可迭代对象中的元素按照位置关系一次性赋值给多个变量。这是Python里非常优雅的特性，能大幅简化代码。

最基础的用法：

a, b = 1, 2

右边本质上是元组(1, 2)，左边则是对它拆包。这个语法也天然支持交换两个变量的值：

a, b = b, a

不需要中间变量temp，代码可读性比传统写法提升不少。

拆包对列表、元组、字符串都适用，只要是可迭代对象就行：

x, y, z = [1, 2, 3] first, second = "hi"

函数返回多个值时，接住返回值本身就是拆包：

def get_user_info(): return "王五", 28, "广州" name, age, city = get_user_info()

3.2 星号操作符的多场景应用

当可迭代对象的元素数量不确定时，用星号操作符可以把多余的元素收集成一个列表，实现可变数量拆包：

first, *middle, last = [1, 2, 3, 4, 5] # first = 1, middle = [2, 3, 4], last = 5

这个写法在很多场景下都能替代切片。以前要取列表第一个和最后一个元素，你要写nums[0]和nums[-1]，现在一行拆包搞定。处理不定长数据时更香，比如解析一行日志，第一个字段是日志级别，最后一个字段是时间戳，中间字段数量不固定，level, *content, timestamp = log_line.split()直接完成。

星号拆包还可以用在函数调用中，把列表展开成位置参数：

args = [1, 2, 3] result = add(*args) # 相当于 add(1, 2, 3)

双星号收集的是关键词参数，它把字典的属性名和值展开成一个个关键字参数：

def register(name, age): print(name, age) user_dict = {"name": "赵六", "age": 22} register(**user_dict)

这是拆包在函数定义的补充——用*args和**kwargs收集任意数量的参数。很多Python库的源码里都大量使用这种写法实现灵活的API。

3.3 嵌套结构的拆包与占位符使用

实际业务中数据往往不是一层结构，嵌套拆包可以一次性把深层数据取出来：

data = [("张三", [85, 92]), ("李四", [78, 80])] for name, (score1, score2) in data: print(name, score1, score2)

这里的(score1, score2)就是在拆包内层的列表。字典配合items()进行嵌套拆包最常用：

fruits_price = {"apple": 3.5, "banana": 2.0} for fruit, price in fruits_price.items(): print(f"{fruit}: {price}")

有时候你只关心部分元素，其他元素不想要。Python允许用下划线作为占位符：

name, _, city = ("张三", 25, "北京")

多个不关心的元素可以写成*_，一次性吸收所有剩余内容：

first, *_, last = [1, 2, 3, 4, 5]

这种写法在遍历嵌套结构时非常实用，比如你拿到一个三元组的列表，但只关心第一个和第三个字段，直接a, _, c = item，比用下标访问清晰得多。

3.4 拆包与函数参数的经典搭配

拆包最经典的应用场景在函数定义和调用之间。定义一个参数列表灵活的函数，可以这样写：

def build_url(base, *paths, **query): url = base.rstrip("/") for path in paths: url += "/" + path.strip("/") if query: query_str = "?" + "&".join(f"{k}={v}" for k, v in query.items()) url += query_str return url

调用方式可以非常灵活：

build_url("https://api.example.com", "users", "detail", id=123, lang="zh")

*paths收集了可变的位置参数，**query收集了所有的查询参数。这种设计在写公共工具函数、框架代码时几乎是标配。理解了拆包，你才真正看得懂别人写的这类函数。

拆包还有一个重要应用场景——从CSV或数据库查询结果中逐行提取字段：

rows = [("001", "张三", 6000), ("002", "李四", 7500)] for emp_id, name, salary in rows: print(f"{emp_id}: {name}, 月薪{salary}")

SQL查询返回的每一行本质上就是一个元组，拆包让数据处理代码自然流畅，不会出现满屏的row[0]、row[1]这种难维护的下标访问。

4. 推导式：一行代码构建新容器

4.1 列表推导式：语法糖里的效率担当

推导式是Python中最具特色的语法之一。它的思想是：用一个表达式描述“如何从一个可迭代对象生成新列表”，而不是用多行循环逐个append。

基础语法只有一句话：[表达式 for 变量 in 可迭代对象]

squares = [x * x for x in range(10)] # [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

等价的多行循环写法：

squares = [] for x in range(10): squares.append(x * x)

推倒式短短一行，不仅代码量减少，执行效率也比循环append略高。因为列表推导式的内部实现针对这种情况做了优化，避免了多次调用append方法带来的开销。在数据量不大时差异感觉不到，但处理几十万条数据时，推导式节省的时间非常可观。

加上条件过滤后，推导式会变得更强大：

even_squares = [x * x for x in range(20) if x % 2 == 0] # 只保留偶数x的平方

这个写法等价于循环里先判断再append。你还可以在推导式里使用嵌套循环：

pairs = [(x, y) for x in range(3) for y in range(3)] # [(0, 0), (0, 1), (0, 2), (1, 0), (1, 1), (1, 2), (2, 0), (2, 1), (2, 2)]

在处理列表中的字典数据、把一个数据格式转换成另一种格式这类场景里，列表推导式都是首选工具。比如前端系统里的字典管理，后端接口返回的往往是一个包含多个字典对象的列表，你想提取所有可用的value字段，一行[item["value"] for item in dict_list if item.get("status") == "enabled"]就能完成全部筛选和提取。

4.2 字典推导式：键值对的高效生成

字典推导式的语法和列表推导式相似，区别在花括号和冒号：

square_map = {x: x * x for x in range(5)} # {0: 0, 1: 1, 2: 4, 3: 9, 4: 16}

这可以用来快速反转字典的键和值：

original = {"a": 1, "b": 2, "c": 3} inverted = {value: key for key, value in original.items()} # {1: 'a', 2: 'b', 3: 'c'}

这个操作在业务中很有用，比如你有一张映射表，想按值反查键的时候，反转一次让后面的程序查询效率大幅提升。

从一个普通列表构造字典也很常见：

students = ["张三", "李四", "王五"] score_dict = {name: 0 for name in students} # {"张三": 0, "李四": 0, "王五": 0}

推导式还可以加条件过滤，生成满足条件的子集。比如统计一段文本中每个字符的出现次数，用字典推导式配合计数器：

text = "hello world" char_count = {char: text.count(char) for char in set(text)}

需要提醒的是，text.count(char)会对每个字符都完整遍历一遍文本，如果文本很长，这种写法的效率并不高。更好的方式是用循环逐个统计，或者用collections.Counter。但作为理解字典推导式的一个例子，它简洁得让人印象深刻。

4.3 集合推导式：去重与变换一步完成

集合推导式长得和字典推导式很像，区别是没有冒号：

words = ["hello", "world", "hello", "python", "world"] unique_lengths = {len(word) for word in words} # {5, 6}

这个集合推导式同时完成了三件事：遍历所有单词、计算每个单词的长度、自动去重。结果是所有不同长度的集合。

一个更贴近实战的场景，从一批URL中提取所有域名并去重：

urls = [ "https://example.com/page1", "https://example.com/page2", "https://api.test.com/v1", "https://example.com/page3" ] domains = {url.split("/")[2] for url in urls} # {'example.com', 'api.test.com'}

一行代码完成解析、提取、去重三个操作。处理爬虫和日志分析任务时，这类场景几乎是天天遇到的。如果你没有集合推导式，就得写至少四到五行代码。

4.4 生成器推导式：大数据的省内存方案

生成器推导式的语法和列表推导式几乎一样，只要把方括号换成圆括号：

gen = (x * x for x in range(10))

区别在于，gen是一个生成器对象，而不是一个真正的列表。它不会一次性把所有元素计算出来存在内存里，而是每次迭代时按需计算下一个值。这在处理大数据集时是决定性的差异。

举个例子，你想计算前一百万个整数的平方和：

total = sum(x * x for x in range(1_000_000))

如果用列表推导式，[x * x for x in range(1_000_000)]会创建一个包含一百万个整数的列表，内存占用几十MB甚至上百MB。而生成器推导式几乎不占额外内存，按需计算一个加一个，内存占用是常数级别的。

需要注意，生成器对象只能迭代一次，没有索引，也不能用len()获取长度。如果数据只需要从头到尾遍历一次，一律优先考虑生成器表达式。如果需要随机访问或多次遍历，才转换回列表。

4.5 推导式的取舍与可读性边界

推导式虽然香，但并不是所有场景都适合。我在团队代码审查时经常看到一些“炫技式”的推导式，一个表达式里塞了三个循环加两个条件，读起来极其痛苦。这种代码虽然执行效率高，但维护成本也高，一旦需要修改逻辑，几乎必须整个重写。

一个简单的判断标准：如果一段推导式超过两行，或者嵌套超过一层，就不要硬写成推导式，老老实实用循环。可读性永远比代码短更重要。在实际工作中，代码是写给人看的，机器只是顺带执行。一个让人一眼就能看懂的循环，远胜过一个需要逐层拆解的推导式。

性能和可读性之间的平衡，我的经验是：小数据量（几千到几万条）直接用推导式，怎么舒服怎么写；大数据量（几十万条以上）用生成器表达式或循环；只有确定性能瓶颈在列表构建上，才考虑复杂的优化写法。数据结构本身的复杂度，通常是性能瓶颈的主要来源，而不是构建列表这一层。

5. 常见问题与排查技巧实录

5.1 可变对象引发的哈希报错

这个问题出现频率非常高：用列表当字典的键，或者把列表放进集合里，Python抛出一个TypeError: unhashable type: 'list'。

我记得有次处理配置数据，从JSON读出来一个嵌套结构，想用某个列表字段做缓存键，直接写了cache_key = user["tags"]，结果一运行就报错。当时第一反应是“Python怎么这么不灵活”，后来理解了哈希表的原理才明白，这是有道理的——列表是可变的，内容随时会变，如果它能做键，哈希值就得跟着变，那整个哈希表的索引就全乱了。

解决办法很简单：把列表转成元组再作为键。cache_key = tuple(user["tags"])。如果列表里又嵌入了列表，就需要先递归转成嵌套元组，或者用json.dumps把整个结构序列化成字符串。

5.2 遍历字典时修改字典导致运行时报错

写统计代码时很容易犯这个错：

scores = {"张三": 60, "李四": 80, "王五": 55} for name, score in scores.items(): if score < 60: del scores[name] # 抛出 RuntimeError: dictionary changed size during iteration

字典迭代过程中改变字典大小，Python会直接报错，这是为了保护迭代器的安全。很多人遇到这个情况会很困惑：“我明明只是删个元素而已。”

正确做法有两种。第一种是遍历字典的副本：

for name, score in list(scores.items()): if score < 60: del scores[name]

第二种是用字典推导式重建一个新字典：

scores = {name: score for name, score in scores.items() if score >= 60}

后面这种写法更优雅、更Pythonic，而且效率更高。这也再次说明推导式在实际业务中的价值——它不只是语法糖，还能避开很多坑。

5.3 切片拷贝的浅层陷阱

切片返回新列表，很多人以为这就是完全独立的副本，但在嵌套结构上会出问题：

matrix = [[1, 2], [3, 4]] copy_matrix = matrix[:] copy_matrix[0].append(99) print(matrix) # [[1, 2, 99], [3, 4]] —— 原列表也变了！

原因在于切片复制的是外层列表的引用关系，内层子列表本身没有复制，新旧列表共享同一份子列表对象。我在处理二维数组或列表嵌套字典时被这个坑折腾过好几次。

解决办法取决于需求。如果只修改外层（增删子列表），浅拷贝就够用。如果需要完全独立的内层副本，用深拷贝：

import copy real_copy = copy.deepcopy(matrix)

或者对每个子列表单独做一次浅拷贝：

new_matrix = [row[:] for row in matrix]

这个列表推导式对每一行执行切片，生成新的子列表，从而实现了二维层面的复制。理解这个区别，在处理二维结构、导入数据、构建矩阵时能避免很多莫名其妙的数据污染。

5.4 元组中的可变元素带来的“假不可变”

前面提到过元组里放列表，列表内容可以修改。这个特性在业务上有个典型场景：你想用一个元组表示一行配置信息，其中一个字段是可选的标签列表。那么元组的不可变性只保护了“字段数量不变”和“标签列表引用不变”，标签列表里的内容是可以增删的。

如果业务上确实需要完全不可变的结构，可以考虑把标签也改成元组，或者使用不可变的数据类型。在Python标准库中，frozenset是集合的不可变版本，它可以作为字典的键；但列表没有对应的不可变版本，只能自己转成元组。

5.5 常见问题速查表

这个速查表我建议直接收藏。排查问题的时候先对照着看，大部分初学者常见的容器类问题都能从这里找到答案。

6. 四个容器的选型决策与典型应用场景总结

在实际写代码的时候，最关键的还是“用什么容器解决问题”。我总结了一个简单的决策流程，每次不确定时都按这个顺序想：

首先，看是否需要按键查找数据。需要就选字典，否则继续判断下一步。其次，看是否需要保持元素的插入顺序。需要就考虑列表或元组；不需要就考虑集合。再次，看数据集合是否允许重复元素。允许重复用列表或元组，不允许重复用集合。最后，看数据是否会被修改。会被修改用列表，不会被修改用元组。

把这四个问题走一遍，容器选型基本不会出错。举个例子，一个爬虫任务要抓取一批商品ID，要求去重、保持顺序、后续还要参考原来的抓取批次，这时候列表配合集合去重的思路就派上用场了——列表保存最终结果，集合用于快速判断某个ID是否已经存在。

另一个例子，后端接口返回的配置数据，结构固定、字段名确定，直接用字典接收。如果配置项是一个固定不变的列表，用元组封装，可以防止代码其他地方不小心修改它。数据分析场景中，需要对一组数值求均值、方差、排序，直接列表处理，配合各种内置函数用起来最顺手。

还有人在问“前端系统管理下的字典管理一般有啥用”，实际上在前后端交互中，字典数据本质上就是一堆键值映射，后端返回一个字典列表，前端拿到后渲染下拉框选项、状态标签。处理这种字典列表时，Python的字典推导式和列表推导式可以快速完成字段筛选、格式转换、数据校验。理解了这一层，你看到字典管理这类需求就不会觉得神秘了。

7. 综合练习：用拆包和推导式解决真实问题

讲了这么多，不如来一个完整的实战案例。假设你要处理一份学生成绩单，数据结构是一个嵌套列表，每个元素包含学生姓名和成绩列表，任务是筛选出所有及格学生的姓名，并把成绩按从高到低排序输出。

students = [ ("张三", [85, 92, 78]), ("李四", [58, 72, 65]), ("王五", [90, 88, 95]), ("赵六", [45, 60, 40]) ]

首先，用拆包遍历所有学生，计算每个人的平均分，保留及格的同学：

passed = [] for name, scores in students: avg_score = sum(scores) / len(scores) if avg_score >= 60: passed.append((name, avg_score))

再用列表推导式做一次排序和格式化输出：

passed_sorted = sorted(passed, key=lambda x: x[1], reverse=True) for rank, (name, avg) in enumerate(passed_sorted, start=1): print(f"第{rank}名: {name}, 平均分: {avg:.1f}")

运行结果：

第1名: 王五, 平均分: 91.0 第2名: 李四, 平均分: 65.0 第3名: 张三, 平均分: 85.0

等等，张三的平均分是85，排序应该在李四前面，但输出结果显然不对。这里暴露了一个问题：字典和列表的排序是按输入的固有顺序处理的，李四和张三的顺序错了。

实际代码中的passed列表顺序是按students原始顺序产生的，排序时reverse=True按平均分降序排，应该是“王五、张三、李四”。如果你复现出来的结果和预期不符，说明代码哪个环节写错了。在真实开发中这种逻辑错误很难一眼看出来，所以建议先把每个步骤的中间结果打印出来检查：

passed = [] for name, scores in students: avg_score = sum(scores) / len(scores) print(f"检查: {name}, 各科成绩{scores}, 平均分{avg_score:.2f}") if avg_score >= 60: passed.append((name, avg_score))

这种“先打印、再排查”的方式，是调试一切Python代码的基础功。不要觉得多打印几行是浪费时间，排查一次诡异的逻辑错误往往比写十行打印语句更耗时。

上面的练习里，拆包出现在三个地方：遍历学生数据时拆出姓名和成绩、在打印排序结果时从元组中拆出排名对应的姓名和平均分。推导式虽然没有直接出现，但如果换成用推导式构造平均分列表，代码会变成：

averages = [(name, sum(scores) / len(scores)) for name, scores in students] passed = [(name, avg) for name, avg in averages if avg >= 60] passed_sorted = sorted(passed, key=lambda x: x[1], reverse=True)

对于这个数据量，两种写法差别不大。但当数据量上升到十万行时，推导式的性能优势就会明显体现出来。

拆包和推导式这两个特性，单独看似乎都是“语法便捷”，但组合使用之后，代码的表现力和可读性会有一个质的提升。它们让Python在处理数据密集型任务时能用更少的代码表达更复杂的逻辑，同时保持代码的可维护性，这也是Python在数据分析、爬虫、自动化脚本领域广受欢迎的核心原因之一。

我给初学者的建议是：不要觉得这些语法特性“花里胡哨”，一定要在平时练习中强制自己使用。每写一个循环，先想想能不能用推导式；每写一个函数，想想能不能用拆包让参数传递更简洁。用上一个月，你会发现自己的编码水平和代码风格会有明显的变化。我带的几个实习生，从只会写循环append到熟练用推导式，大概用了两三周，再看他们早期写的代码，风格完全判若两人。

还有一个学习技巧，遇到不理解的数据结构行为，直接在交互式环境里做实验。Python的REPL（Read-Eval-Print Loop）是最好的数据结构学习工具，输入一句话立刻能看到结果，比翻任何教程都直观。花一晚上把所有数据结构的增删改查、切片、推导式都手动敲一遍，比看十遍文章记忆得更深刻。