Python数据结构与推导式：从构建到转化的高效编程路径

Python新手最容易产生的一个错觉，就是把数据结构单纯当作“装东西的容器”，把推导式当成“一种高级循环写法”。但真正跑过项目之后你会发现，数据结构决定了你写代码的思考方式，而推导式决定了你把一种结构转成另一种结构的速度。从列表到字典，从字典到集合，从集合到生成器，如果全程只靠 for 循环和临时变量，代码会越写越乱；而一旦你掌握了推导式的底层逻辑，很多所谓“复杂的数据处理”，其实就是一行表达式的事。

这篇文章会从构建和转化两条线展开：先带你重新理解 Python 里最常用的列表、元组、字典、集合到底应该怎么选、怎么建、怎么互相转，再把列表推导式、字典推导式、集合推导式和生成器表达式逐个拆开揉碎，配合爬虫清洗、数据分析、量化交易里的真实场景，告诉你哪些地方用推导式能极大提效，哪些地方千万不能用。无论你是刚学 Python 的入门者，还是已经在写业务脚本但总觉得代码不够利索的开发者，这篇文章都值得花二十分钟刷一遍。

1. 为什么说数据结构和推导式是Python的“任督二脉”

1.1 数据结构是程序的骨架

很多人学数据结构时，第一反应是“这是算法课的考点，和日常写脚本有什么关系”。我早期也有这种想法，直到被一段维护成本极高的代码折磨之后才明白：数据结构选的合不合理，直接决定了代码能不能继续往下写。

你可以把数据结构想象成不同功能的收纳工具。列表是一排开放的抽屉，适合按顺序存放同类物品，比如用户上传的文件路径、待处理的日志行；元组是封好口的抽屉，一旦放进去就不能改，适合存坐标、RGB颜色、数据库查询返回的单行记录；字典是带标签的档案柜，每个标签对应一个值，查起来快得惊人，适合存用户信息、配置项、词频统计；集合则是一张自动去重的核查表，只关心“有没有”，适合做交集、差集、白名单过滤。

从算法复杂度的角度看，列表和字典的差距非常明显。列表查找一个元素，最坏情况下要遍历整个列表，时间复杂度是 O(n)；字典按键查找，底层是哈希表，平均复杂度是 O(1)。也就是说，一万条数据时你可能感觉不到差异，但到了百万、千万级别，用列表硬找和用字典直接查，差距可能就是几分钟和几毫秒的差别。这就是为什么所有数据结构相关教程都在强调“选型优先”。

构建数据结构时，很多新手习惯先建一个空列表，然后 append，建一个空字典，然后赋值 key，这当然没错。但只看这一步就够了吗？远远不够。真正的核心能力是“根据业务需要，用最合适的方式把数据组织起来”。比如统计一段文本中每个单词出现的次数，你会想到用字典，但如果你先学的是 C 语言，习惯了数组，可能第一反应是维护两个平行列表，一个存单词、一个存次数，这样不仅代码丑陋，查找和更新也都很麻烦。Python 里defaultdict、Counter这些工具就是建立在字典之上的高级构建方式，它们让“构建数据结构”这件事从手动挡变成了自动挡。

1.2 推导式：从“怎么建”到“怎么转”的高效表达

理解了数据结构的骨架地位，下一个问题就是：如何快速构建和转化这些结构。推导式就是 Python 给我们的答案。

举个例子，给你一个数字列表，想挑出所有偶数并乘以 2，得到一个平方后的新列表。用传统循环，你至少要写三行：

nums = [1, 2, 3, 4, 5, 6] result = [] for n in nums: if n % 2 == 0: result.append(n * 2)

用列表推导式，一行就完了：

result = [n * 2 for n in nums if n % 2 == 0]

这看起来只是语法糖，但它背后代表了一种思维转变：你不再关心“如何一步步填充列表”的过程，而是直接声明“我要从 nums 里取出满足条件的元素，映射成新值，构成一个新列表”。这个过程，本质上就是数据结构的构建和转化。

为什么说推导式是“任督二脉”？因为在实际业务里，程序的大部分工作都是在处理数据：从接口拿到 JSON 列表，要转成字典方便查询；从数据库读出一堆行，要转成集合做去重；从日志里提取关键字段，要生成新的列表。这些操作如果用循环+临时变量，每个都要写好几行，还得小心维护中间状态。而推导式把“遍历—筛选—映射—收集”四件事压缩成一个表达式，代码量少，出错概率也低，读起来像自然语言。

当然，推导式不是银弹。它适合“纯净的映射和过滤”，不适合带副作用或逻辑特别复杂的场景。这个后面我专门用一个章节讲清楚。

1.3 适用人群与学习路线

这篇文章的内容，适合下面几类人：

第一，刚入门 Python，已经会写基本语法，但刷题或写脚本时总觉得代码冗长，想找到更高级的写法。第二，做数据分析、爬虫、自动化脚本的工程师，日常工作大量涉及数据结构转换，想把代码写得既快又稳。第三，准备面试或复习数据结构与算法的同学，想系统地理解 Python 内置数据结构的底层能力和推导式的适用边界。

学习路线我建议这样走：先不看推导式，把列表、元组、字典、集合的构建和常用方法练熟；然后尝试用循环写数据转化，理解每一步在干什么；最后再用推导式改写，体会表达方式的差异。这个顺序看起来很慢，但能帮你真正建立“构建与转化”的直觉，而不是只会复制粘贴语法。

另外提一句环境准备，热词里很多人搜 Python 安装、VSCode 环境配置，建议直接装 Python 3.8 以上的版本，用 VSCode 加 Python 插件，或者 PyCharm 社区版，都行。推导式相关的特性在 Python 3 里已经非常稳定，不需要额外的包，只要解释器版本别太老就可以。

2. 动手构建Python核心数据结构

2.1 列表与元组：有序数据的构建和选择

列表是 Python 里最灵活的数据结构，可以存任意类型，可以增删改查。它的构建方式主要有四种：直接用方括号字面量、用list()转换、用.append()逐个添加、用列表推导式批量生成（后面单独讲）。

# 字面量 fruits = ["apple", "banana", "cherry"] # list() 转换 chars = list("hello") # ["h", "e", "l", "l", "o"] # 先空后加 numbers = [] numbers.append(10) numbers.append(20) # 批量生成（列表推导式） squares = [x**2 for x in range(10)]

这里有一个很多人踩过的坑：如果你想创建一个包含三个空列表的二维结构，写出matrix = [[]] * 3，得到的三个列表其实是同一个对象的引用。你修改其中一个，其他两个也会跟着变。我调试的时候遇到过这种诡异问题，最后发现是*操作符复制的是引用而不是内容。正确的做法是：

matrix = [[] for _ in range(3)]

元组和列表最大的区别是不可变。很多人觉得元组只是“不能修改的列表”，但其实它的真正价值在于“结构固定”。比如函数的多个返回值、一组 GPS 坐标、数据库一行记录，用元组天然安全，因为你不小心修改它时会立刻报错，能把很多潜在 bug 挡在运行前。元组构建方式同样多样：

point = (3, 5) rgb = tuple([255, 128, 0])

列表和元组之间可以互转：list(tuple_obj)、tuple(list_obj)。这种转化在需要“临时修改”的时候特别有用。比如你拿到一个元组里的配置，想在运行时动态调整其中一项，就可以先转成列表，改完再转回元组，保持接口的不可变约定。

2.2 字典与集合：键值映射与唯一性的实现

字典是 Python 里使用频率最高的映射结构。构建方式多得让人眼花缭乱：

# 字面量 user = {"name": "张三", "age": 28} # dict() 关键字 user = dict(name="张三", age=28) # fromkeys：批量构建含默认值的字典 keys = ["apple", "banana"] default_dict = dict.fromkeys(keys, 0) # {"apple": 0, "banana": 0} # zip 两个列表合成字典 names = ["张三", "李四"] ages = [28, 25] user_map = dict(zip(names, ages))

zip把两个序列对应位置打包成一组组元组，再用dict()转成字典，这本身就是一种非常经典的“构建与转化”技巧。做数据分析时经常遇到两个平行列表，一个放字段名，一个放字段值，用这招合并成字典，比手动循环干净得多。

集合的构建有一个容易忽视的坑：空集合不能用{}，必须用set()，因为{}是空字典。集合的字面量需要包含元素，比如{1, 2, 3}。它和字典共用花括号语法，所以学的时候要有意识地分清。

# 集合构建 unique_nums = {1, 2, 2, 3, 3, 3} # {1, 2, 3} # 从列表去重 unique_names = set(["张三", "李四", "张三"]) # 空集合 empty_set = set()

集合的核心特性是元素唯一且可哈希。它天生适合去重、成员判断、集合运算。比如判断某个用户 ID 是否在 VIP 名单里，用集合比用列表快得多。

2.3 数据结构之间的互相转化

构建是第一步，转化才是真正拉开差距的地方。实际业务里，数据很少一开始就是你要的形态。最常见的转化场景：

• 列表去重并保留原顺序。直接list(set(lst))会丢失顺序，因为集合是无序的。要保持顺序，可以用dict.fromkeys(lst)：

lst = [3, 1, 2, 3, 1] unique_ordered = list(dict.fromkeys(lst)) # [3, 1, 2]

dict.fromkeys会保留插入顺序，而且键唯一，所以这个技巧在很多 Python 3.6+ 环境里都能稳定工作。

• 列表转字典。如果列表本身是成对的元组，直接用dict(lst)。如果两个单独列表，用zip。

pairs = [("name", "张三"), ("age", 28)] user_dict = dict(pairs) keys = ["name", "age"] values = ["张三", 28] user_dict2 = dict(zip(keys, values))

• 字典转列表。有时候我们只想取字典的键、值或全部键值对。

user = {"name": "张三", "age": 28} list_of_items = list(user.items()) # [("name", "张三"), ("age", 28)] list_of_keys = list(user.keys()) # ["name", "age"] list_of_values = list(user.values()) # ["张三", 28]

• 字典的键视图和值视图也可以直接传给集合构造函数，用于集合运算。

set(user.keys()) set(user.values())

转化过程中有一类隐蔽问题：字典的键必须是可哈希的，所以列表、字典这类可变结构不能直接作为键或集合元素。如果你试图把一个列表放进集合，解释器会报TypeError: unhashable type: 'list'。遇到这种情况，可以考虑把列表转成元组再存。这个细节在写缓存、状态标记、复杂键查询时特别重要。

3. 推导式完全拆解：语法、逻辑与性能

3.1 列表推导式：从循环到表达式的思维转换

列表推导式的基本语法是：

[expression for item in iterable if condition]

它等价于下面的循环：

result = [] for item in iterable: if condition: result.append(expression)

理解执行顺序很关键：先执行后面的for，再执行前面的expression，中间可选的if用来过滤。你可以把expression想象成“对每个满足条件的 item 做映射”。

我在教别人时常用一个类比：列表推导式像一条流水线，元素从一端进来，经过传送带上的过滤和加工，从另一端出来变成新列表。你不需要手动开一个空箱子，也不需要手动把加工好的产品放进去，流水线自动完成了装箱。

实际应用时，条件过滤经常是多条件的：

nums = [10, 21, 32, 43, 54, 65] res = [n // 2 for n in nums if n > 30 and n % 2 == 0]

注意and不能写成两个if连放的错误理解，其实多个if也是等价的：

res = [n // 2 for n in nums if n > 30 if n % 2 == 0]

两者效果相同，但可读性上更推荐用and合并成一个条件。

列表推导式还有一个隐藏优势：它会优先在底层用 C 循环执行，比手动 for 循环的 Python 解释器逐行执行要快一些。当然这个快不是数量级差距，但当你处理几十万元素时，确实能感受到流畅度的提升。

3.2 字典推导式与集合推导式：一个表达式搞定映射与去重

字典推导式的语法和列表推导式类似，只是用花括号，并且表达式部分是键: 值：

{key_expression: value_expression for item in iterable}

非常典型的例子是把一个字典的键和值反转：

original = {"a": 1, "b": 2, "c": 3} reversed_dict = {v: k for k, v in original.items()} # {1: "a", 2: "b", 3: "c"}

这个操作在查询映射关系反转时极其方便。比如你原本用城市名查邮编，现在需要根据邮编查城市，反转一下就是新字典。

字典推导式还可以从一个列表批量构建带计算值的字典。比如统计词频：

words = ["apple", "banana", "apple", "cherry"] word_count = {word: words.count(word) for word in set(words)}

不过这里有个性能隐患：words.count(word)对每个词都会扫描整个列表，整体是 O(n^2)。如果数据量大，更推荐用Counter。我们在讲推导式的“适用边界”时，也要记得它并不是所有场景的最优解。

集合推导式语法类似，但生成的是去重后的集合：

nums = [1, 2, 2, 3, 4, 4, 5] squared_set = {x**2 for x in nums} # {1, 4, 9, 16, 25}

它特别适合把列表转成集合进行去重或集合运算，同时还允许你在转化过程中做一些映射。比如从一堆文件名中提取扩展名：

files = ["a.py", "b.txt", "c.py", "d.jpg"] extensions = {f.split(".")[-1] for f in files} # {"py", "txt", "jpg"}

注意集合推导式的结果不保证顺序，所以如果后续需要稳定顺序，请再转成列表排序。

3.3 生成器表达式：当数据量大到内存扛不住时

生成器表达式和列表推导式非常相似，区别只是把方括号换成圆括号：

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

它不会立刻生成全部元素，而是在你迭代时逐个产出，这就是“惰性求值”。处理超大文件或无限数据流时，列表推导式可能直接吃光内存，而生成器表达式只占用几乎固定的内存。

我举个例子，假设你有一个 1GB 的日志文件，需要求所有行数字之和。直接用列表推导式把所有行转成数字再求和，会一次性构建一个百万级元素的列表，内存占用巨大；用生成器表达式配合sum()，每一行只被处理一次，内存几乎不变：

total = sum(int(line.strip()) for line in open("huge.log") if line.strip().isdigit())

注意生成器表达式外面必须用sum()这样的函数消费它，否则它自己不会主动执行。

生成器表达式的一个限制是：它只能被迭代一次。你第一次用for遍历它，第二次再遍历时会得到空结果。这个话题经常有新手踩坑。我的建议是：如果你需要多次遍历相同的数据，那就老老实实用列表；如果只是做一次性的统计、筛选、传参，生成器表达式更合适。

3.4 推导式中的条件过滤与嵌套循环

推导式同样支持嵌套循环。语法顺序和普通循环是一致的，先写外层 for，再写内层 for：

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

它等价于：

result = [] for x in range(3): for y in range(3): result.append((x, y))

嵌套推导式最常见的用途是展平二维列表：

matrix = [[1, 2], [3, 4], [5, 6]] flat = [num for row in matrix for num in row] # [1, 2, 3, 4, 5, 6]

这里容易搞混顺序：for row in matrix是外层，for num in row是内层。写的时候记住“左读顺序就是循环嵌套顺序”。

我个人的经验是，嵌套超过两层就不建议用推导式了，可读性会急剧下降。你可以拆成普通函数或多个步骤。比如下面这个三层嵌套，我能看懂，但维护时绝对会头疼：

[(a,b,c) for a in range(5) for b in range(a) for c in range(b) if c > 0]

这种代码在一个月后回看，要花很长时间才能反应出它的逻辑。项目里最重要的不是炫技，而是让同事和自己都能快速理解。

条件在推导式里的位置也很有意思。比如(x for x in lst if condition)中的if是过滤内层；而(f(x) if condition else g(x) for x in lst)中的if-else是映射表达式的一部分。很多人容易混淆，记住：if在for后面是过滤，if-else在for前面是选择映射。例子：

nums = [3, -1, 2, -5] # 过滤负数，只保留正数 positive = [n for n in nums if n > 0] # 映射：正数不变，负数转成绝对值 abs_map = [n if n > 0 else -n for n in nums]

这个区分在实际代码中经常用到，特别是处理清洗逻辑时。

4. 实战：用推导式完成常见的数据构建与转化

4.1 爬虫数据清洗：过滤空值、去除重复、提取字段

爬虫最麻烦的不是发请求，而是清洗抓回来的数据。你从网页、接口拿到一堆列表，里面掺杂着None、空字符串、缺失字段、重复数据。这时候推导式是你的救命工具。

假设爬虫返回的是很多字典，每个字典表示一条商品信息，但有些商品缺少标题，有些价格是空字符串：

raw_products = [ {"title": "iPhone 15", "price": "5999"}, {"title": "", "price": "2999"}, {"title": "MacBook", "price": None}, {"title": "iPhone 15", "price": "5999"}, {"title": None, "price": "1999"}, ]

先过滤掉标题为空或价格为空的条目：

valid_products = [ item for item in raw_products if item.get("title") and item.get("price") ]

再去重。因为字典本身不可哈希，不能直接放进集合去重。可以先用 “标题+价格”的元组作为去重键，构建一个临时字典再取回原值：

unique_products = list({(p["title"], p["price"]): p for p in valid_products}.values())

这里字典推导式把元组键映射到原始字典，后出现的重复键会覆盖先出现的，最终.values()就得到去重后的列表。这一行代码同时完成了“构建映射”和“转化回列表”两件事。

再比如，我们需要从原始数据中只提取价格字段，并转成浮点数列表，方便后续统计分析：

prices = [float(p["price"]) for p in valid_products if p["price"].isdigit()]

这种写法比手动循环加append清爽太多，而且清洗逻辑集中在一行，别人读起来也能一眼看懂规则。

4.2 数据分析场景：用字典推导式构建统计聚合

数据分析中，经常需要按某个字段做聚合。比如一份销售数据包含城市和销售额：

sales = [ {"city": "北京", "amount": 1200}, {"city": "上海", "amount": 980}, {"city": "北京", "amount": 1500}, {"city": "广州", "amount": 700}, ]

如果你试图用一个字典推导式直接完成聚合求和，会失败，因为推导式对每个元素只执行一次映射，不适合做累加。正确的方式是先初始化结构，再循环累加：

total = {} for s in sales: total[s["city"]] = total.get(s["city"], 0) + s["amount"]

这里dict.get(key, 0)是构建聚合结果的关键技巧：键不存在时返回 0，避免KeyError。但是，我们仍然可以用字典推导式做一些初始化工作，比如把每个城市的初始金额设为 0：

cities = [s["city"] for s in sales] amount_total = dict.fromkeys(set(cities), 0) for s in sales: amount_total[s["city"]] += s["amount"]

虽然这个初始化不是必须的，但在数据量大、后续需要多次更新时，先建好结构能避免反复判断键是否存在。

如果数据源是两列平行列表，比如城市列表和金额列表，可以直接用字典推导式来构建映射：

cities = ["北京", "上海", "北京", "广州"] amounts = [1200, 980, 1500, 700] # 去重后的城市列表作为键 city_amount = {c: amounts[cities.index(c)] for c in set(cities)}

不过要注意，cities.index(c)返回第一次出现的索引，遇到重复城市会取第一个金额，所以这种写法只适合“城市只出现一次”的场景。如果要做聚合，还是前面循环累加更稳妥。

数据分析里另一个常用操作是用Counter快速统计频率。Counter本质上就是字典的子类，但它底层是 C 优化过的：

from collections import Counter word_counts = Counter(["apple", "banana", "apple", "cherry"])

我可以把它和字典推导式结合，比如只保留出现次数大于 1 的词：

hot_words = {word: count for word, count in word_counts.items() if count > 1}

这种“先用 Counter 构建，再用字典推导式筛选转化”的组合，在日常数据处理里非常实用。

4.3 量化交易场景：快速比对股票代码集合与交集运算

量化交易里经常要处理股票代码列表。比如一个策略筛选出看涨股票，另一个策略筛选出低波动股票，最后要取两者的交集作为最终买入池。用列表和循环当然能实现，但用集合运算明显更清晰。

先定义两个策略的候选列表：

strategy_a = ["600519", "000858", "000333", "002415"] strategy_b = ["600519", "000333", "300750", "601318"]

如果你需要把列表转换成集合，直接用set()就行，但有时候你需要先做条件筛选再转集合，这时集合推导式就派上用场了：

set_a = {code for code in strategy_a if code.startswith("60")} set_b = {code for code in strategy_b if not code.startswith("00")}

然后直接做交集和差集：

buy_list = set_a & set_b # 两个策略都看好的股票 only_a = set_a - set_b # 只在策略A中出现的股票

集合运算不仅写起来方便，底层哈希表实现让它在数据量非常大时依然很快。这在回测、盘中选股场景里很有价值，因为每次交易信号更新都要求毫秒级响应。

如果股票代码需要映射到股票名称，可以用字典推导式从一个“代码-名称”列表构建映射：

stock_info = [ ("600519", "贵州茅台"), ("000858", "五粮液"), ("000333", "美的集团"), ] name_map = {code: name for code, name in stock_info}

然后结合买入池，快速找出对应的名称：

buy_names = [name_map[code] for code in buy_list if code in name_map]

这段代码里，集合交集已经帮我们把范围缩小了，再用列表推导式去查找名称，整个过程清晰又高效。你可以看到，数据结构的“构建”和“转化”在量化场景里是无处不在的。

4.4 从脚本到exe：推导式在打包场景的注意点

热词里很多人搜“python 打包成exe”，说明不少小伙伴写脚本是要发给同事用的。打包时，推导式这种写法本身没有兼容性问题，但有几个小坑值得提一下。

第一，如果打包环境里的 Python 版本比你开发环境低，某些推导式特性可能不可用。比如 Python 3.7 才保证字典保持插入顺序，Python 3.8 才支持海象运算符配合推导式，所以尽量统一版本。第二，调试时不要过度依赖一条很长的推导式。打包后的程序一旦报错，错误信息往往指向整行，定位问题很麻烦。我写代码时会故意把复杂的业务逻辑拆成几步，保留中间变量，方便打包后排查逻辑错误。第三，生成器表达式在打包成 exe 后，处理大数据时要格外注意文件句柄的释放，比如open()配合生成器后要在外部手动关闭文件，否则可能造成文件占用。

这些经验不是推导式本身的问题，而是工程化时容易忽略的细节。掌握推导式能让你写出更 Pythonic 的代码，但好代码还要兼顾可调试性和可维护性。

5. 常见问题、踩坑记录与性能优化

5.1 推导式容易踩的坑

学推导式时，有几个问题几乎每个人都遇到过。

第一个坑是嵌套顺序搞反。比如二维列表展平，很多人会写成[num for num in row for row in matrix]，结果就是NameError，因为执行到第一个num in row时row还没定义。正确顺序是外层循环在前。写之前先在脑子里过一遍 for 循环的嵌套顺序，再套进推导式里。

第二个坑是字典推导式键冲突。如果两个元素生成相同的键，后面的值会覆盖前面的值，而且不会有任何提示。比如上面去重时，这可能是你想要的，但如果你本想保留多个值，就会悄悄丢数据。所以使用前一定要确认键的唯一性。

第三个坑是变量作用域。Python 3 的推导式有独立的局部作用域，不会把循环变量泄漏到外部，这点比 Python 2 好很多。但如果你在推导式里调用了一个修改外部列表的函数，就属于副作用，代码会变得很难预测。比如：

data = [] result = [data.append(x) for x in range(5)]

这会把data变成[0,1,2,3,4]，同时result变成[None,None,None,None,None]，因为list.append()返回None。这种写法几乎永远是反模式，不要这样写。

第四个坑是过度嵌套。推导式本身是简洁工具，嵌套超过两层后代码可读性严重下降，甚至不如普通循环清晰。遇到这种情况，我建议拆开成多个推导式或函数，性能不会差多少，但可维护性会好很多。

5.2 什么时候不要用推导式

我见过不少人把推导式用得很嗨，结果代码里出现了“一行超人”，别人根本看不懂。以下场景，我强烈建议放弃推导式：

需要副作用时。比如循环里要print、要更新多个外部变量、要写入文件，这些操作不应该作为推导式的 expression。推导式设计初衷是“纯净的映射和过滤”，不是在列表生成过程中偷偷做额外操作。这个时候，用普通循环反而更清晰。

逻辑复杂时。如果条件判断有多层 if 嵌套，或者表达式非常长，比如超过 80 个字符，或者需要写一个辅助函数才能让表达式变得可读，那就别硬用推导式。你可以先写辅助函数，在推导式里调用它，这样既保持简洁又不损失逻辑表达。

需要异常处理时。如果循环体内有 try/except，推导式无能为力。比如解析字符串成数字，可能会遇到无法解析的值，你需要跳过或设默认值。这种场景建议用循环或map+ 处理函数。

大数据量且需要复用数据时。如果只想遍历一次，用生成器表达式；如果需要多次访问，必须用列表，否则生成器第二次遍历就是空的。这个前面讲过，但很多新手还是会踩。

5.3 性能对比：推导式、map/filter与显式循环

很多人关心推导式到底快不快。我做了一个简单测试，构建一个包含 100 万个整数的列表，分别用三种方式过滤偶数并平方：

• 显式 for 循环
• map配合filter
• 列表推导式

在常见 Python 3.10 环境下，结果大致如下（不同机器略有差异，但趋势一致）：

列表推导式快的原因，是它底层用 C 循环优化了 append 操作，减少了每次迭代时 Python 字节码的开销。map和filter本身也是 C 实现，但由于需要额外函数调用，有时不一定比推导式快。

要说明的是，性能不是选择写法的唯一标准。一个清晰、容易维护的 for 循环，远胜过一个花哨但没人看得懂的推导式。我的判断标准很简单：如果推导式一行能说明白逻辑，且不超过 80 字符，就用它；否则就拆开。

5.4 实用建议：让推导式可读性更高的几个习惯

最后分享几个我自己写推导式的习惯，都是日常踩坑总结出来的。

给变量起有意义的名字。不要吝啬变量名长度。比如[p["price"] for p in products if p["price"]]里的p可以换成prod，虽然多写点字，但读起来舒服很多。

把条件抽出来定义成函数。如果过滤条件比较复杂，比如“价格大于 100 且库存大于 0 且标题不含促销词”，可以定义一个is_valid_product()函数，然后在推导式里调用它。这样推导式依旧一行，但所有业务逻辑都放在函数里，便于测试和维护。

一行太长就换行。Python 的推导式允许在方括号内换行。把 for、if、expression 分开写，配合缩进，能极大提升可读性：

result = [ compute(item) for item in items if condition1(item) if condition2(item) ]

不要只盯着列表推导式。很多时候，生成器表达式、字典推导式、集合推导式才是真正合适的选择。你需要根据“输出是什么”来决定用哪种结构。

另外一个技巧是，把推导式当作数据管道的一段。比如清洗数据时，可以先用列表推导式过滤，再用字典推导式映射，再用集合推导式去重。每一步只做一件事，组合起来就是清晰的数据流。这比在一个大循环里既过滤又映射又去重要容易理解得多。

我个人的体会是，推导式学起来不难，难的是在合适的场景选择合适的结构。写代码时习惯先问自己：我现在的输入是什么？输出应该是什么？中间需要保留哪些临时信息？这三个问题想明白后，推导式的写法往往是水到渠成。最后再分享一个小技巧：遇到不确定的推导式行为，直接在 REPL 里写一个最小样例跑一遍，比空想快得多。这个习惯帮我避免了好几次线上 bug，希望你也能用上。