1. 从一段“看起来能用但跑起来想砸键盘”的代码说起列表推导式、生成器、迭代器这三个词放在一起很多刚学 Python 的朋友第一反应是“语法糖合集”第二反应是“面试八股文”。但我可以很负责任地讲这三个东西真正决定了一个 Python 开发者写出来的代码是“能跑”还是“跑得优雅、跑得省内存、跑得让接手的人想请你吃饭”。我最早接触列表推导式是在处理一批日志文件的时候。当时的需求很简单从几千个文本文件里提取所有包含特定关键字的行去掉首尾空白再统一转成小写。我一开始写了一个 for 循环append 了七八行跑起来也没问题。后来一位前辈看了一眼说“你这逻辑一行就够了”然后写下了[line.strip().lower() for f in files for line in open(f) if keyword in line]。那一刻我意识到列表推导式不只是“短”它背后代表的是一种声明式的数据变换思维。再往后当我开始处理几十 GB 的日志、做数据清洗和特征工程的时候列表推导式突然不够用了——内存直接爆掉。这时候生成器登场了。生成器让我明白一个道理不是所有数据都需要同时存在于内存里。而迭代器则是支撑这一切的底层协议理解了迭代器你才能真正理解 Python 的 for 循环到底在干什么为什么for i in range(10**9)不会卡死为什么文件对象可以直接被遍历。这篇内容我打算把这三个概念从“会用”讲到“用对”再讲到“用出花来”。不管你是刚学完基础语法的新手还是写了几年 Python 但一直没系统梳理过这块的老手我都尽量用实际场景和踩坑经验把这件事讲透。核心关键词就三个列表推导式、生成器、迭代器但我会把它们串成一条完整的“数据处理链路”来讲而不是孤立地背语法。2. 列表推导式不只是短而是思维方式的转变2.1 列表推导式到底解决了什么问题先看一个最朴素的场景。假设你有一个列表nums [1, 2, 3, 4, 5, 6]你想得到每个元素的平方组成一个新列表。传统写法是这样的squares [] for n in nums: squares.append(n * n)这段代码没有任何问题可读性也好。但列表推导式的写法是squares [n * n for n in nums]很多人把列表推导式理解成“for 循环的缩写”这个理解只对了一半。更准确的说法是列表推导式是一种从可迭代对象构建列表的声明式表达式。它的重点不在于“循环”而在于“我要一个什么样的列表”。这个区别很关键。当你写 for append 的时候你的思维是“过程式”的先创建空列表然后一步步往里加。当你写列表推导式的时候你的思维是“声明式”的我要的列表是“对 nums 里每个 n 求平方”。前者描述“怎么做”后者描述“要什么”。我个人的经验是当数据变换逻辑能用一句话描述清楚的时候就用列表推导式当逻辑需要多步、有条件分支嵌套、或者需要副作用比如打印日志的时候就老老实实写 for 循环。强行把复杂逻辑塞进推导式只会让代码变成“一行看不懂的密码”。2.2 条件过滤与嵌套循环的正确打开方式列表推导式支持条件过滤语法是把if放在for后面evens [n for n in nums if n % 2 0]也支持if-else表达式但位置不一样if-else是放在for前面的labels [even if n % 2 0 else odd for n in nums]这两个位置的区别是新手最容易搞混的地方。记住一个口诀for 后面的 if 是“筛选”for 前面的 if-else 是“变换”。筛选决定“要不要这个元素”变换决定“这个元素变成什么”。嵌套循环也支持比如展开一个二维列表matrix [[1, 2, 3], [4, 5, 6], [7, 8, 9]] flat [x for row in matrix for x in row]这里for row in matrix是外层循环for x in row是内层循环顺序和写嵌套 for 循环是一致的。我见过有人把顺序写反结果报NameError原因就是内层循环引用了还没定义的变量。注意列表推导式里嵌套超过两层可读性会急剧下降。我个人的底线是最多两层 for条件不超过两个。超过这个复杂度宁可拆成多行 for 循环或者抽成一个独立函数。代码是给人看的不是给编译器炫技的。2.3 性能真相列表推导式真的更快吗很多人说列表推导式比 for append 快这个说法基本成立但要理解为什么。CPython 在执行列表推导式的时候走的是一条专门优化的字节码路径。它不需要在每次迭代时去查找append方法普通 for 循环里squares.append每次都要做属性查找也不需要在 Python 层面反复调整列表大小。底层LIST_APPEND这个字节码比调用方法要快不少。我实测过一个简单场景对一百万个整数求平方写法耗时大致内存占用for append约 0.08 秒完整列表列表推导式约 0.05 秒完整列表生成器表达式约 0.0000001 秒创建几乎为零可以看到列表推导式确实快一些但这个差距在大多数业务场景里可以忽略不计。真正需要在意性能的时候往往是数据量到了百万、千万级别这时候列表推导式的“快”已经救不了你了因为内存才是瓶颈。这时候就该生成器上场了。所以我的建议是用列表推导式是为了表达清晰顺带享受性能红利而不是为了性能硬凑列表推导式。如果一段逻辑用 for 循环写更清楚那就用 for 循环别为了“显得 Pythonic”而牺牲可读性。2.4 那些年我在列表推导式上踩过的坑第一个坑是变量泄漏。在 Python 2 里列表推导式的循环变量会泄漏到外层作用域Python 3 修复了这个问题。如果你还在维护老代码这一点要特别注意。第二个坑是副作用。有人会在列表推导式里调用有副作用的函数比如results [save_to_db(item) for item in items]这行代码能跑但语义很怪——你创建了一个列表但真正想要的是“保存”这个副作用列表本身可能根本不用。这种写法会让读代码的人困惑。有副作用就用 for 循环这是铁律。第三个坑是大列表内存爆炸。我曾经写过一个[process(line) for line in open(huge.log)]文件几个 GB结果内存直接吃满进程被系统干掉。正确做法是用生成器表达式把方括号换成圆括号或者直接用 for 循环逐行处理。这个坑我在下一节会详细讲。3. 生成器让内存不再成为你的天花板3.1 生成器表达式与 yield两种写法一个本质生成器最直观的价值就是省内存。回到刚才那个大文件场景如果我只是想逐行处理不需要把所有结果同时放在内存里那就不应该用列表推导式。生成器表达式就是把列表推导式的方括号换成圆括号gen (line.strip() for line in open(huge.log) if line.strip()) for line in gen: process(line)这行代码创建的时候几乎不占内存每次 for 循环才真正读取一行、处理一行。文件多大都不怕因为内存里始终只有当前这一行。另一种定义生成器的方式是用yield关键字写生成器函数def read_lines(path): with open(path) as f: for line in f: stripped line.strip() if stripped: yield stripped这两种方式本质是一样的都是“惰性求值”。区别在于生成器表达式适合简单的单行变换生成器函数适合复杂逻辑可以包含多步处理、条件分支、甚至多个 yield。我个人在项目里的选择标准是逻辑能写在一行且不超过 80 个字符用生成器表达式否则用生成器函数。生成器函数还有个好处是可以加文档字符串、可以复用、可以单独测试。3.2 惰性求值一次只做一件事的哲学生成器最核心的特性是惰性求值lazy evaluation。它不会一次性把所有结果算出来而是你问它要一个它才算一个。这个特性带来的好处不只是省内存还有可以处理无限序列。比如斐波那契数列def fib(): a, b 0, 1 while True: yield a a, b b, a b这个生成器可以无限产出斐波那契数但你只取前十个也没问题from itertools import islice first_ten list(islice(fib(), 10))如果用列表推导式或者普通函数返回列表这个无限序列根本没法表示因为内存装不下。生成器让“无限”变得可操作。另一个好处是管道式处理。你可以把多个生成器串起来形成一个数据处理管道lines read_lines(huge.log) keywords (line for line in lines if ERROR in line) messages (extract_message(line) for line in keywords) for msg in messages: send_alert(msg)每一层都是惰性的数据像水流一样从源头流到终点中间不会积压。这种写法在处理日志、流式数据、ETL 场景里非常常见也是我认为生成器最有价值的应用模式。3.3 生成器的状态机本质与 send 方法生成器不只是“能省内存的迭代器”它本质上是一个可以暂停和恢复的状态机。每次yield的时候函数的执行状态局部变量、执行位置都被保存下来下次调用next()的时候从原地继续。这个特性衍生出了send()方法可以往生成器里传值def accumulator(): total 0 while True: x yield total if x is None: break total x acc accumulator() next(acc) # 启动生成器返回 0 acc.send(10) # 返回 10 acc.send(20) # 返回 30这个模式可以用来写协程、状态机、或者交互式的数据处理逻辑。不过说实话send()在日常业务代码里用得不多更多是在框架底层、异步编程、或者特定算法里出现。新手可以先了解有这个能力不必强行使用。提示生成器一旦被耗尽迭代到结尾就不能再用了。如果你需要重复遍历要么重新创建生成器要么把结果转成列表。我见过有人把生成器传给两个函数第二个函数拿到的是空的排查了半天才发现是生成器被第一个函数耗尽了。3.4 生成器实战分批读取大文件并做聚合讲一个我实际做过的场景。有一个几十 GB 的日志文件我要统计每种错误码出现的次数但内存有限不能一次性读入。思路是用生成器逐行读取用字典做聚合每读一行更新一次计数。这样内存占用只和错误码的种类数有关和文件大小无关。from collections import defaultdict def iter_log_lines(path): with open(path, encodingutf-8, errorsignore) as f: for line in f: yield line.rstrip(\n) def extract_code(line): # 假设日志格式里错误码在某个固定位置 if ERROR not in line: return None parts line.split() for p in parts: if p.startswith(CODE): return p[5:] return None counter defaultdict(int) for line in iter_log_lines(huge.log): code extract_code(line) if code: counter[code] 1 for code, count in sorted(counter.items(), keylambda x: -x[1]): print(code, count)这个方案跑几十 GB 文件毫无压力内存占用稳定在几 MB。如果换成列表推导式先把所有行读进来机器直接罢工。这里有个细节值得说open()返回的文件对象本身就是一个迭代器逐行读取是惰性的。所以其实iter_log_lines里那个 for 循环可以简化但包一层生成器函数的好处是可以统一处理编码、换行符、过滤空行等逻辑让主流程更干净。4. 迭代器Python 循环背后的那套协议4.1 可迭代对象与迭代器的区别很多人把“可迭代对象”和“迭代器”混为一谈其实它们有明确区别。**可迭代对象Iterable**是实现了__iter__方法的对象它承诺“我可以被遍历”。列表、元组、字典、集合、字符串、文件对象都是可迭代对象。**迭代器Iterator**是同时实现了__iter__和__next__方法的对象。__iter__返回迭代器自身__next__返回下一个元素没有元素时抛出StopIteration。关系是这样的可迭代对象通过iter()函数可以拿到它的迭代器迭代器通过next()函数逐个取值。nums [1, 2, 3] # 可迭代对象 it iter(nums) # 迭代器 next(it) # 1 next(it) # 2 next(it) # 3 next(it) # StopIterationfor 循环的本质就是先调用iter()拿到迭代器然后反复调用next()直到捕获StopIteration为止。理解了这一点你就能理解为什么 for 循环可以遍历任何可迭代对象也能理解为什么生成器可以直接被 for 遍历——因为生成器本身就是迭代器。4.2 自己实现一个迭代器理解协议的最好方式想真正搞懂迭代器最好的办法是自己写一个。比如实现一个倒计时迭代器class Countdown: def __init__(self, start): self.current start def __iter__(self): return self def __next__(self): if self.current 0: raise StopIteration value self.current self.current - 1 return value for n in Countdown(5): print(n) # 5 4 3 2 1这个类同时实现了__iter__和__next__所以它既是可迭代对象又是迭代器。__iter__返回 self表示“我就是自己的迭代器”。__next__负责产出下一个值并在结束时抛出StopIteration。写一遍这个类你对 for 循环的理解会立刻上一个台阶。很多“为什么我的对象不能被 for 遍历”的问题答案就是缺了__iter__方法。4.3 迭代器的“一次性”特性与常见误用迭代器有一个非常重要的特性它是一次性的。一旦遍历完就空了再遍历什么也拿不到。it iter([1, 2, 3]) list(it) # [1, 2, 3] list(it) # []第二次list(it)得到空列表因为迭代器已经耗尽了。这个特性导致了很多隐蔽的 bug。比如你把一个迭代器传给两个函数第一个函数遍历完了第二个函数拿到的是空的。我踩过的一个坑是用map()或filter()返回的迭代器赋值给一个变量后在调试时打印了一次结果正式逻辑里就取不到数据了。因为打印的时候已经把迭代器耗尽了。解决办法有两个一是需要多次遍历时把迭代器转成列表二是每次遍历时重新创建迭代器。选择哪个取决于数据量和内存限制。注意生成器、map、filter、zip、文件对象返回的都是迭代器都具有一次性特性。而列表、元组、字典、集合是可迭代对象可以反复遍历。这个区别在实际开发中非常关键。4.4 itertools迭代器工具的标准库宝库Python 标准库里的itertools是迭代器相关操作的宝库用好了能省很多手写循环的功夫。我挑几个最常用的说说。islice可以对迭代器做切片但不会像列表切片那样一次性取全部from itertools import islice list(islice(fib(), 10)) # 取前十个斐波那契数chain可以把多个可迭代对象串成一个from itertools import chain list(chain([1, 2], [3, 4], [5])) # [1, 2, 3, 4, 5]groupby可以按 key 分组但要求输入已经按 key 排好序from itertools import groupby data [(a, 1), (a, 2), (b, 3)] for key, group in groupby(data, keylambda x: x[0]): print(key, list(group))tee可以把一个迭代器复制成多个解决一次性问题from itertools import tee it1, it2 tee(iter([1, 2, 3])) list(it1) # [1, 2, 3] list(it2) # [1, 2, 3]不过tee底层会缓存数据如果两个迭代器消费速度差距很大缓存会膨胀内存占用可能反而比直接转列表还高。所以tee适合消费速度接近的场景不适合一个快速消费一个慢慢消费的场景。5. 三者协同构建一条高效的数据处理流水线5.1 从数据源到结果一个完整的管道设计把列表推导式、生成器、迭代器放在一起看它们其实对应数据处理流水线的不同阶段。数据源通常是可迭代对象文件、数据库游标、网络流。中间处理阶段用生成器做惰性变换和过滤避免中间结果占内存。最终结果如果需要多次访问或者需要随机索引用列表推导式物化成列表如果只需要遍历一次保持生成器即可。我设计过一个日志分析管道大致结构是这样的def read_logs(path): with open(path, encodingutf-8, errorsignore) as f: for line in f: yield line.rstrip(\n) def filter_errors(lines): for line in lines: if ERROR in line: yield line def parse_fields(lines): for line in lines: parts line.split(|) if len(parts) 4: yield { time: parts[0], level: parts[1], code: parts[2], message: parts[3], } pipeline parse_fields(filter_errors(read_logs(app.log))) error_codes [item[code] for item in pipeline]这个管道里read_logs、filter_errors、parse_fields都是生成器函数数据一行一行流过内存占用恒定。最后一步用列表推导式把错误码收集起来因为后面可能要做统计和排序需要多次访问。这种“生成器做管道列表推导式做收口”的模式是我在数据处理里最常用的组合。它兼顾了内存效率和代码清晰度。5.2 性能对比列表推导式 vs 生成器 vs 普通循环为了让大家有个直观感受我做过一组对比测试处理一千万个整数做平方和过滤方案内存峰值耗时适用场景列表推导式约 400 MB约 0.6 秒数据量小需要多次访问生成器表达式约 几 MB约 0.9 秒数据量大只需遍历一次普通 for 循环约 400 MB约 0.8 秒逻辑复杂需要副作用生成器函数 聚合约 几 MB约 1.0 秒流式聚合内存敏感可以看到生成器在内存上有压倒性优势耗时略高但差距不大。列表推导式在需要完整列表时最方便。普通 for 循环在逻辑复杂时最清晰。选择哪个取决于你的约束条件内存紧不紧、数据要不要复用、逻辑复不复杂。没有银弹只有权衡。5.3 惰性求值的边界什么时候不该用生成器生成器虽好但不是万能的。有几种情况我会刻意避免用生成器。第一种是需要多次遍历。如果结果要被多个消费者使用生成器的一次性特性会导致 bug不如直接转成列表。第二种是需要随机访问。生成器只能顺序取不能gen[5]这样索引。需要随机访问就老老实实物化成列表。第三种是调试困难。生成器的报错堆栈往往不如普通函数直观因为执行是分散在多次next()调用里的。如果一段逻辑很复杂、容易出错我倾向于先用普通函数写清楚确认逻辑正确后再考虑是否改成生成器。第四种是数据量其实很小。如果数据只有几百条用生成器带来的那点内存优势毫无意义反而增加了理解成本。这时候列表推导式更直接。提示判断标准很简单——如果数据量在内存里放得下且需要多次使用就用列表如果数据量大或者只需要用一次就用生成器。不要为了“显得高级”而滥用生成器。6. 常见问题与排查技巧实录6.1 生成器耗尽导致的空结果这是最常见的坑。现象是明明数据源有数据但第二个消费者拿到的是空的。排查思路检查这个生成器是不是被前面的代码遍历过了。常见于调试时打印、日志记录、或者传给多个函数。解决方法要么每次重新创建生成器要么在第一次遍历时就转成列表。如果数据量大不能转列表考虑用itertools.tee复制但要注意缓存膨胀问题。6.2 列表推导式里的变量作用域问题Python 3 里列表推导式有自己的作用域循环变量不会泄漏到外层。但生成器表达式和列表推导式在闭包里的行为可能出乎意料。比如funcs [lambda: i for i in range(3)] [f() for f in funcs] # [2, 2, 2]不是 [0, 1, 2]原因是 lambda 捕获的是变量i的引用而不是值。等 lambda 被调用时i已经是最后一个值了。解决办法是用默认参数绑定当前值funcs [lambda ii: i for i in range(3)] [f() for f in funcs] # [0, 1, 2]这个坑在写回调、事件处理器的时候特别容易遇到。6.3 迭代器与可迭代对象混淆导致的 TypeError报错信息通常是X object is not iterable。原因是你的对象没有实现__iter__方法。排查思路确认你的类有没有定义__iter__。如果定义了__next__但没定义__iter__它也不是可迭代对象。两个都要有。另一个常见错误是X object is not an iterator原因是你在一个可迭代对象上直接调用了next()。正确做法是先iter()再next()。6.4 常见问题速查表问题现象可能原因解决方法第二个函数拿到空数据生成器/迭代器被耗尽重新创建或转列表内存爆满用了列表推导式处理大数据改用生成器表达式not iterable报错类缺少__iter__实现__iter__方法not an iterator报错对可迭代对象直接next()先iter()再next()lambda 捕获变量值不对闭包捕获引用用默认参数绑定生成器报错堆栈难懂惰性执行分散先用普通函数验证逻辑6.5 几个我压箱底的实操技巧第一个技巧用生成器做数据校验管道。把校验规则拆成多个生成器每个负责一类校验数据流过时逐层过滤出错的记录单独收集。这样校验逻辑清晰内存占用低。第二个技巧列表推导式里避免调用耗时函数。如果变换函数很慢列表推导式会阻塞直到全部完成。这时候用生成器 逐条处理可以边处理边输出进度用户体验更好。第三个技巧用yield from简化嵌套生成器。Python 3.3 之后可以用yield from sub_gen代替for x in sub_gen: yield x代码更简洁性能也略好。第四个技巧调试生成器时先转列表。生成器出错时堆栈不直观我通常会在调试阶段先list(gen)看看结果对不对确认逻辑正确后再改回生成器。7. 我个人的一些使用心得写了这么多年 Python我对这三个东西的态度是列表推导式是日常主力生成器是处理大数据的利器迭代器是理解 Python 循环机制的钥匙。列表推导式我几乎每天都在用但我会控制复杂度超过两层嵌套就拆开。生成器我在处理日志、流式数据、ETL 管道时必用它帮我省下的内存和避免的 OOM 事故数不胜数。迭代器协议我平时不直接写但理解它让我在遇到“为什么这个对象不能遍历”“为什么这个迭代器空了”这类问题时能快速定位原因。如果让我给初学者一个建议那就是先把列表推导式用熟再理解生成器的惰性求值最后搞懂迭代器协议。这个顺序符合认知规律也符合实际使用的频率。另外不要迷信“一行流”。我见过太多为了炫技把逻辑塞进一行列表推导式的代码读起来像解密。代码的第一目标是让人看懂第二目标才是让机器执行。Python 之禅里那句“可读性很重要”放在这里再合适不过。最后分享一个我最近才用上的小技巧用生成器表达式配合any()和all()做短路判断。比如判断一个大文件里是否存在某行满足条件has_error any(ERROR in line for line in open(huge.log))这行代码一旦找到第一个匹配就立刻返回 True不会读完整个文件。比先读全部再判断高效得多。类似的还有all()做全量校验next()配合默认值做查找。这些小组合用好了代码既简洁又高效。
