要理解 Python 生成器Generator和 yield 关键字光看语法定义是没用的。我印象最深的是几年前第一次用 Python 处理一份几个 G 的日志文件当时脑子一热直接 readlines()程序瞬间吃掉几个 G 内存机器直接卡死。后来我才明白Python 里有个东西叫生成器它能让我“一条一条地读边读边处理”内存占用从 G 级变成 M 级。这篇文章就把生成器和 yield 的来龙去脉、执行机制、实战场景和常见坑一次性讲透。不管你是刚接触 Python 的入门选手还是已经在写数据处理、爬虫或者量化策略的进阶玩家只要你遇到过“数据量大到内存扛不住”“希望数据按需计算而不是一次性全部生成”这类问题这篇笔记都值得你花十分钟看一遍。看完之后你会发现惰性求值不是一种玄学它就是一种非常实用、非常优雅的编程思维。1. 从内存爆炸说起生成器到底解决了什么问题1.1 一次真实的“内存翻车”经历先聊一个很现实的场景。假设你要处理一份 5GB 的交易流水文件每行是一笔记录你需要统计每个小时的成交笔数和总金额。很多人的第一反应是with open(trades.txt, r, encodingutf-8) as f: lines f.readlines()这行代码看起来很自然但readlines()会把整个文件的所有行一次性读进内存。5GB 的文本经过字符对象包装后内存占用轻松翻倍甚至翻三倍16GB 内存的机器直接变幻灯片。我当时就是这么栽的。问题出在哪出在“一次性生成完整序列”的思路上。你真的需要同时拥有五百万行数据吗不需要。你需要的只是每行的统计结果处理完一行、丢弃一行最后保留聚合后的统计值就够了。生成器解决方案是这样写的def read_byte_lines(file_path): with open(file_path, r, encodingutf-8) as f: for line in f: yield line.strip()准确说这里能节省内存的关键是for line in f本身因为文件对象已经是可迭代的流式对象了。但在更多场景下我们需要自定义数据流、做链式变换、构造无限序列这时候生成器和 yield 就是主角。1.2 “按需生产”vs“一次做完”惰性求值的本质为了理解生成器和 yield我把惰性求值Lazy Evaluation用一个生活例子解释给你听。普通函数就像你点了一道“满汉全席”厨房必须把所有菜全部做完了再一次性端上桌。如果吃不完剩下的菜就浪费了占着桌面内存还得费劲收拾。生成器则像你在一家精致的日料店坐在吧台前师傅做一道、你吃一道。做好的菜立刻送到你面前吃完后师傅才动手做下一道。你随时可以结账走人师傅也不会提前做出一百道菜堆在台面上。这个“师傅做一道、你吃一道”的模式在 Python 里就被称为“惰性求值”。它解决的不是计算速度问题而是资源占用与生产节奏的问题。计算只在被“索取”的时候才发生数据只保留当前这一条用完之后上一项就可以被垃圾回收。惰性求值带来的直接收获有四个内存占用低永远只保存当前正在处理的一个元素而不是整个序列。启动速度快生成第一个元素后就能开始工作不用等全部数据生成完毕。理论上可支持无限序列比如质数流、斐波那契数列普通列表永远装不下生成器却可以一直 next。代码表达更灵活可以把复杂的处理流程拆成多个生成器的组合像管道一样串联起来。要理解这个过程先记住一个核心结论一个包含yield关键字的函数在被调用时并不会立即执行函数体内的任何代码而是返回一个生成器对象。函数体内的代码只有在迭代这个生成器比如调用next()时才会真正运行。这句话是整个生成器机制的灵魂。2. yield 的执行机制函数如何做到“走一半就暂停”2.1 一步步拆解生成器函数的执行过程与其空谈理论不如看一个具体的例子我来逐步演示执行顺序。假设你写了这么一段函数def count_down(n): print(进入生成器函数) while n 0: print(f即将产出 {n}) yield n print(fyield 之后恢复执行n 现在是 {n}) n - 1 print(生成器结束)当你执行gen count_down(3)时屏幕上不会出现任何输出。普通函数在调用时已经知道全部结果了但生成器函数只是构造了一个生成器对象放在那。现在调用next(gen)函数真正开始执行第一次 next(gen): 输出: 进入生成器函数 输出: 即将产出 3 返回: 3函数执行到yield n这一行时n 的值作为返回值交给调用者函数的状态包括局部变量 n、当前执行到的位置被整体冻结。再次调用next(gen)输出: yield 之后恢复执行n 现在是 3 输出: 即将产出 2 返回: 2注意看输出顺序函数并没有重新从头开始而是从上次挂起的yield那一行之后继续往下走执行n - 1然后回到while循环再次遇到yield挂起。这个执行顺序说明了 yield 的本质yield 不是 return它只是临时交出执行权函数本身还活着。yield 把函数的执行状态局部变量、指令指针、栈帧封装在生成器对象里下次调用 next 时从断点处恢复。这和操作系统的协程思想非常接近。再对比一下普通函数普通函数一旦return整个栈帧就被销毁了所有局部变量都消失了。生成器函数则像一个“可恢复的暂停帧”这也是后来 Python 协程库 asyncio 能流行的底层基础之一。2.2 进阶玩法send 反向传值、yield from 与生成器表达式除了next()从外部拉取数据生成器还支持用send()向内部推数据。这相当于建立了一条双向通道。来个简单例子——一个可重置的累加器def accumulator(): total 0 while True: value yield total if value is None: continue total value用send()往里传值acc accumulator() print(next(acc)) # 必须先“启动”生成器返回 0 print(acc.send(10)) # 传入 10返回 10 print(acc.send(5)) # 传入 5返回 15send(10)做了两件事先把 10 送入生成器内部作为上一次挂起处yield的表达式结果赋给value然后继续执行到下一次 yield 挂起并返回计算结果。还有一个高频使用的写法是yield from。它的作用是把一个生成器或可迭代对象里的每个值逐个“转发”出去相当于循环 yield 的语法糖。一个典型的场景是递归遍历目录树def list_py_files(path): from pathlib import Path for entry in Path(path).iterdir(): if entry.is_dir(): yield from list_py_files(entry) # 递归委托 elif entry.suffix .py: yield entryyield from会递归地把子目录里所有.py文件依次 yield 给最外层调用者。如果写成普通的嵌套 for 循环会麻烦不少。除了函数Python 还有一种更简洁的语法——生成器表达式squares (x * x for x in range(1000000))注意最外层是圆括号不是方括号。这种写法得到的不是列表而是一个生成器对象。与列表推导式[x * x for x in range(1000000)]相比生成器表达式不会一次性创建一百万个元素而是逐个计算。差别在内存上尤其明显——列表推导式可能占用几十 MB生成器表达式只占用几个字节。3. 实战拆解三个典型的生成器应用场景3.1 超大文件流式处理几 GB 日志轻松读我最早用生成器就是处理大文件。这里给出一份可以直接套用的实现。def read_large_file(file_path): with open(file_path, r, encodingutf-8) as f: for line in f: yield line.rstrip() def count_keyword_hits(file_path, keyword): count 0 for line in read_large_file(file_path): if keyword in line: count 1 return count这段代码看起来平淡无奇但执行过程中同一时间内存里只有一行字符串。即使文件有 200 万行内存占用也保持稳定不会随文件大小增长。这种流式读入方式在日志监控、ETL 数据管道、超大数据集清洗中相当常用。如果你需要做多级处理比如先过滤包含某个关键字的行再做字段拆分可以写成管道叠加filtered (line for line in read_large_file(trades.txt) if line.startswith(2025-)) fields (line.split(,) for line in filtered) total sum(float(row[3]) for row in fields if len(row) 4)三行代码三个生成器串联数据像流水线上的工件一样从一个环节流向下一个环节。这就是函数式编程里“惰性管道”的 Python 形态。3.2 无限序列与数据流斐波那契只是开胃菜普通列表没办法表达无限这个概念。你不可能创建一个含有无限个元素的 list但生成器可以。只要没人来取值它就一直挂起不占额外内存。def fibonacci(): a, b 0, 1 while True: yield a a, b b, a b只取前十个from itertools import islice first_ten list(islice(fibonacci(), 10)) print(first_ten) # [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]注意这里用到了itertools.islice它是对无限生成器做“切片”的标准做法因为普通切片操作需要知道序列长度而生成器没有长度这个概念。无限序列的实战价值并不在于算斐波那契本身而在于实时数据流。我见过一个量化场景的简化版用生成器模拟行情切片def tick_stream(): i 0 while True: price 100 (i % 20) * 0.5 yield {seq: i, price: price} i 1策略程序可以边逐 tick 消费边计算移动平均不需要事先拿到全天行情内存恒定还能在任意时刻退出循环停止订阅。这种模型与生产环境中的消息队列消费方式是天然匹配的。3.3 协程雏形用 send 做简单状态机之前在 2.2 节里讲了send()用法它其实可以让我们很容易地实现一个状态机。举个例子假设你要判断一串字符里的括号是否完全匹配可以用一个生成器维护计数状态def bracket_checker(): balance 0 while True: ch yield balance if ch (: balance 1 elif ch ): balance - 1 if balance 0: balance 0外部代码可以这样调用checker bracket_checker() next(checker) # 启动 for ch in ((())(: print(f输入 {ch} 后平衡值: {checker.send(ch)})这种用 yield 挂住状态对象的方式本质上就是协程。Python 3.5 之后 asyncio 正是建立在类似机制之上所以搞清楚 yield 的暂停恢复逻辑后面理解async/await会容易很多。4. 性能实测与选型建议何时值得用生成器4.1 内存和时间开销一次简单对比我先写一个测试脚本分别用列表推导式、生成器表达式、以及手动实现的生成器函数求 1000 万个数平方和import time n 10_000_000 # 方式一列表 start time.time() lst [x * x for x in range(n)] s1 sum(lst) print(列表耗时:, time.time() - start) # 方式二生成器表达式 start time.time() s2 sum(x * x for x in range(n)) print(生成器表达式耗时:, time.time() - start) # 方式三生成器函数 def square_gen(n): for x in range(n): yield x * x start time.time() s3 sum(square_gen(n)) print(生成器函数耗时:, time.time() - start)从我的实测结果看数据量一千万列表推导式因为要分配一个庞大的列表对象耗时约 1.5 秒左右内存占用几百 MB生成器表达式和生成器函数耗时约为 0.8 秒到 1.0 秒内存占用几乎可以忽略。生成器方案不仅省内存在求和这类单遍迭代场景下还更快因为省去了列表构建和元素搬运的开销。但事情要分两面看。如果后续需要反复多次访问同一批数据比如要遍历同一列表 20 遍做聚合生成器就不合适了因为生成器只能单向迭代一次。这种情况下一次性构建列表虽然首次耗时高但后续访问的时间复杂度是 O(1) 的索引总开销反而更优。4.2 工程选型标准一张表快速判断我把经验整理成一条简单决策链。先问自己几个问题数据总量是否非常大甚至无法完整放入内存如果是走生成器。数据是否会无限产生如果是只能走生成器。我是否只遍历一次、且顺序无关如果是生成器很合适。我需要随机访问中间元素吗比如data[5000]如果需要生成器不行得用列表。我需要反复多次遍历同一份数据吗如果遍历次数多、数据可重放可以重新创建生成器或用列表缓存。场景推荐方案原因超大文件逐行处理生成器内存恒定无限序列生成生成器列表无法表示无限单遍聚合计算求和/统计生成器或生成器表达式省内存且速度快需要索引随机访问列表 / 元组生成器无下标访问小数据量多次复用列表构建开销低使用便捷数据管道链式清洗多个生成器串联代码简洁、内存效率高放到业务里判断时我的默认经验是数据规模超过内存可用空间的 20% 时立刻改用生成器流式计算。如果数据只是几千条用列表推导式无可厚非别为了“优雅”而把所有代码都改成生成器过度设计也是一种负担。补充一句关于迭代器与生成器的区别。迭代器是一个更宽泛的概念只要实现了__iter__()和__next__()方法的对象都是迭代器生成器函数产生的对象是迭代器的一种具体实现。平时你可以把生成器当成一种“自动化了”的迭代器——不需要手动定义类、写__next__只要写 yield 就完事。5. 避坑手册那些年我踩过的生成器问题5.1 五个高频报错与多年的细节问题一生成器没有长度不能 len()我第一次对生成器执行len(gen)时直接报错TypeError: object of type generator has no len()。生成器是“未知长度”的流可能无限所以 Python 根本不允许求长度。如果你想知道剩余数量只能遍历计数或者提前用列表装下再 len。问题二生成器只能遍历一次生成器不是可重放的磁带而是单向的自来水管。第一次 for 循环取出所有元素后生成器就空了第二次循环什么也拿不到。gen (x for x in range(5)) print(list(gen)) # [0, 1, 2, 3, 4] print(list(gen)) # []应对办法是如果需要反复遍历每次重新调用生成器函数创建新的生成器对象def data_gen(): yield from range(5) for x in data_gen(): pass for x in data_gen(): # 每次调用都是新对象 pass问题三return 的值不在迭代中出现生成器函数里可以写return它起到“结束迭代”的作用但返回的值不会出现在迭代序列里而是被包装在StopIteration异常的 value 属性中。def gen_with_return(): yield 1 yield 2 return done捕获规则是这样的g gen_with_return() try: while True: print(next(g)) except StopIteration as e: print(返回值:, e.value) # done如果你的 Python 版本在 3.7 之后for 循环对 StopIteration 做了特殊处理看不到这个 “done”只有手动调用 next 时才能捕获到。这一点很容易被忽略。问题四在生成器里分配超大列表有些新手把生成器函数当作普通列表的替代却仍然在函数内部构建了一个大列表def bad_gen(n): data [i * i for i in range(n)] # 又回到一次性构建 for item in data: yield item这样内存问题完全没得到解决只是把压力后移了。正确的做法是把列表推导式也写成生成器表达式的形式或者直接在 yield 前不暂存。问题五无限递归导致递归深度溢出递归生成器虽然好用但无限递归会像普通函数一样触发RecursionError。用yield from展开无限子节点时必须要设置终止条件避免递归层数过多。5.2 一条实用的调试技巧给生成器加“日志”生成器太抽象出错时最难判断执行到哪里。我的习惯是借助打印日志来追踪比如写一个小包装器def debug_wrapper(gen): for item in gen: print(f[debug] 产出: {item}) yield item把任何一个生成器传进 debug_wrapper就能在运行时看到数据流经过的每个元素。特别是多个生成器串联时在某一环插入 debug_wrapper能迅速定位是上游不出数还是下游吞了数据。另外一个好用的官方工具是inspect.getgeneratorstate()它能告诉你生成器当前处于GEN_CREATED、GEN_SUSPENDED、GEN_RUNNING还是GEN_CLOSED状态。调试协程卡住时很有参考价值。5.3 把生成器组合成数据管道这里分享一个让我受用很久的技巧灵活使用itertools.chain把多个生成器合并成一个连续流。from itertools import chain def read_file_a(): yield a1 yield a2 def read_file_b(): yield b1 for line in chain(read_file_a(), read_file_b()): print(line) # a1, a2, b1这种方式在合并多个数据源时特别清爽整个程序从“一堆循环”变成“一条流水线”。再配合itertools.groupby、itertools.filterfalse这些函数你可以搭建出很强大的数据处理编排链路而不用为每个临时结果专门建列表。6. 写在最后惰性求值不仅是语法更是思维习惯如果只能说一句经验我会说在你写任何“先构建整个序列再从头遍历”的代码之前多想一秒钟——这个序列是否真的需要一次性完整存在于内存里如果答案是否定的那么生成器就是更优雅的选择。它不是 Python 里最酷炫的语法但却是“避免内存灾难”和“构建高效数据管道”的利器。当你习惯了用生成器的思维去写代码你会发现很多大流量、大数据量场景下的性能问题根本还没到需要上分布式框架的地步单机加生成器就已经能轻松扛住了。 
长河君 · 2026/10/4 19:13:50 · 阅读 1.2k Python生成器与yield：从内存爆炸到惰性求值实战
要理解 Python 生成器Generator和 yield 关键字光看语法定义是没用的。我印象最深的是几年前第一次用 Python 处理一份几个 G 的日志文件当时脑子一热直接 readlines()程序瞬间吃掉几个 G 内存机器直接卡死。后来我才明白Python 里有个东西叫生成器它能让我“一条一条地读边读边处理”内存占用从 G 级变成 M 级。这篇文章就把生成器和 yield 的来龙去脉、执行机制、实战场景和常见坑一次性讲透。不管你是刚接触 Python 的入门选手还是已经在写数据处理、爬虫或者量化策略的进阶玩家只要你遇到过“数据量大到内存扛不住”“希望数据按需计算而不是一次性全部生成”这类问题这篇笔记都值得你花十分钟看一遍。看完之后你会发现惰性求值不是一种玄学它就是一种非常实用、非常优雅的编程思维。1. 从内存爆炸说起生成器到底解决了什么问题1.1 一次真实的“内存翻车”经历先聊一个很现实的场景。假设你要处理一份 5GB 的交易流水文件每行是一笔记录你需要统计每个小时的成交笔数和总金额。很多人的第一反应是with open(trades.txt, r, encodingutf-8) as f: lines f.readlines()这行代码看起来很自然但readlines()会把整个文件的所有行一次性读进内存。5GB 的文本经过字符对象包装后内存占用轻松翻倍甚至翻三倍16GB 内存的机器直接变幻灯片。我当时就是这么栽的。问题出在哪出在“一次性生成完整序列”的思路上。你真的需要同时拥有五百万行数据吗不需要。你需要的只是每行的统计结果处理完一行、丢弃一行最后保留聚合后的统计值就够了。生成器解决方案是这样写的def read_byte_lines(file_path): with open(file_path, r, encodingutf-8) as f: for line in f: yield line.strip()准确说这里能节省内存的关键是for line in f本身因为文件对象已经是可迭代的流式对象了。但在更多场景下我们需要自定义数据流、做链式变换、构造无限序列这时候生成器和 yield 就是主角。1.2 “按需生产”vs“一次做完”惰性求值的本质为了理解生成器和 yield我把惰性求值Lazy Evaluation用一个生活例子解释给你听。普通函数就像你点了一道“满汉全席”厨房必须把所有菜全部做完了再一次性端上桌。如果吃不完剩下的菜就浪费了占着桌面内存还得费劲收拾。生成器则像你在一家精致的日料店坐在吧台前师傅做一道、你吃一道。做好的菜立刻送到你面前吃完后师傅才动手做下一道。你随时可以结账走人师傅也不会提前做出一百道菜堆在台面上。这个“师傅做一道、你吃一道”的模式在 Python 里就被称为“惰性求值”。它解决的不是计算速度问题而是资源占用与生产节奏的问题。计算只在被“索取”的时候才发生数据只保留当前这一条用完之后上一项就可以被垃圾回收。惰性求值带来的直接收获有四个内存占用低永远只保存当前正在处理的一个元素而不是整个序列。启动速度快生成第一个元素后就能开始工作不用等全部数据生成完毕。理论上可支持无限序列比如质数流、斐波那契数列普通列表永远装不下生成器却可以一直 next。代码表达更灵活可以把复杂的处理流程拆成多个生成器的组合像管道一样串联起来。要理解这个过程先记住一个核心结论一个包含yield关键字的函数在被调用时并不会立即执行函数体内的任何代码而是返回一个生成器对象。函数体内的代码只有在迭代这个生成器比如调用next()时才会真正运行。这句话是整个生成器机制的灵魂。2. yield 的执行机制函数如何做到“走一半就暂停”2.1 一步步拆解生成器函数的执行过程与其空谈理论不如看一个具体的例子我来逐步演示执行顺序。假设你写了这么一段函数def count_down(n): print(进入生成器函数) while n 0: print(f即将产出 {n}) yield n print(fyield 之后恢复执行n 现在是 {n}) n - 1 print(生成器结束)当你执行gen count_down(3)时屏幕上不会出现任何输出。普通函数在调用时已经知道全部结果了但生成器函数只是构造了一个生成器对象放在那。现在调用next(gen)函数真正开始执行第一次 next(gen): 输出: 进入生成器函数 输出: 即将产出 3 返回: 3函数执行到yield n这一行时n 的值作为返回值交给调用者函数的状态包括局部变量 n、当前执行到的位置被整体冻结。再次调用next(gen)输出: yield 之后恢复执行n 现在是 3 输出: 即将产出 2 返回: 2注意看输出顺序函数并没有重新从头开始而是从上次挂起的yield那一行之后继续往下走执行n - 1然后回到while循环再次遇到yield挂起。这个执行顺序说明了 yield 的本质yield 不是 return它只是临时交出执行权函数本身还活着。yield 把函数的执行状态局部变量、指令指针、栈帧封装在生成器对象里下次调用 next 时从断点处恢复。这和操作系统的协程思想非常接近。再对比一下普通函数普通函数一旦return整个栈帧就被销毁了所有局部变量都消失了。生成器函数则像一个“可恢复的暂停帧”这也是后来 Python 协程库 asyncio 能流行的底层基础之一。2.2 进阶玩法send 反向传值、yield from 与生成器表达式除了next()从外部拉取数据生成器还支持用send()向内部推数据。这相当于建立了一条双向通道。来个简单例子——一个可重置的累加器def accumulator(): total 0 while True: value yield total if value is None: continue total value用send()往里传值acc accumulator() print(next(acc)) # 必须先“启动”生成器返回 0 print(acc.send(10)) # 传入 10返回 10 print(acc.send(5)) # 传入 5返回 15send(10)做了两件事先把 10 送入生成器内部作为上一次挂起处yield的表达式结果赋给value然后继续执行到下一次 yield 挂起并返回计算结果。还有一个高频使用的写法是yield from。它的作用是把一个生成器或可迭代对象里的每个值逐个“转发”出去相当于循环 yield 的语法糖。一个典型的场景是递归遍历目录树def list_py_files(path): from pathlib import Path for entry in Path(path).iterdir(): if entry.is_dir(): yield from list_py_files(entry) # 递归委托 elif entry.suffix .py: yield entryyield from会递归地把子目录里所有.py文件依次 yield 给最外层调用者。如果写成普通的嵌套 for 循环会麻烦不少。除了函数Python 还有一种更简洁的语法——生成器表达式squares (x * x for x in range(1000000))注意最外层是圆括号不是方括号。这种写法得到的不是列表而是一个生成器对象。与列表推导式[x * x for x in range(1000000)]相比生成器表达式不会一次性创建一百万个元素而是逐个计算。差别在内存上尤其明显——列表推导式可能占用几十 MB生成器表达式只占用几个字节。3. 实战拆解三个典型的生成器应用场景3.1 超大文件流式处理几 GB 日志轻松读我最早用生成器就是处理大文件。这里给出一份可以直接套用的实现。def read_large_file(file_path): with open(file_path, r, encodingutf-8) as f: for line in f: yield line.rstrip() def count_keyword_hits(file_path, keyword): count 0 for line in read_large_file(file_path): if keyword in line: count 1 return count这段代码看起来平淡无奇但执行过程中同一时间内存里只有一行字符串。即使文件有 200 万行内存占用也保持稳定不会随文件大小增长。这种流式读入方式在日志监控、ETL 数据管道、超大数据集清洗中相当常用。如果你需要做多级处理比如先过滤包含某个关键字的行再做字段拆分可以写成管道叠加filtered (line for line in read_large_file(trades.txt) if line.startswith(2025-)) fields (line.split(,) for line in filtered) total sum(float(row[3]) for row in fields if len(row) 4)三行代码三个生成器串联数据像流水线上的工件一样从一个环节流向下一个环节。这就是函数式编程里“惰性管道”的 Python 形态。3.2 无限序列与数据流斐波那契只是开胃菜普通列表没办法表达无限这个概念。你不可能创建一个含有无限个元素的 list但生成器可以。只要没人来取值它就一直挂起不占额外内存。def fibonacci(): a, b 0, 1 while True: yield a a, b b, a b只取前十个from itertools import islice first_ten list(islice(fibonacci(), 10)) print(first_ten) # [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]注意这里用到了itertools.islice它是对无限生成器做“切片”的标准做法因为普通切片操作需要知道序列长度而生成器没有长度这个概念。无限序列的实战价值并不在于算斐波那契本身而在于实时数据流。我见过一个量化场景的简化版用生成器模拟行情切片def tick_stream(): i 0 while True: price 100 (i % 20) * 0.5 yield {seq: i, price: price} i 1策略程序可以边逐 tick 消费边计算移动平均不需要事先拿到全天行情内存恒定还能在任意时刻退出循环停止订阅。这种模型与生产环境中的消息队列消费方式是天然匹配的。3.3 协程雏形用 send 做简单状态机之前在 2.2 节里讲了send()用法它其实可以让我们很容易地实现一个状态机。举个例子假设你要判断一串字符里的括号是否完全匹配可以用一个生成器维护计数状态def bracket_checker(): balance 0 while True: ch yield balance if ch (: balance 1 elif ch ): balance - 1 if balance 0: balance 0外部代码可以这样调用checker bracket_checker() next(checker) # 启动 for ch in ((())(: print(f输入 {ch} 后平衡值: {checker.send(ch)})这种用 yield 挂住状态对象的方式本质上就是协程。Python 3.5 之后 asyncio 正是建立在类似机制之上所以搞清楚 yield 的暂停恢复逻辑后面理解async/await会容易很多。4. 性能实测与选型建议何时值得用生成器4.1 内存和时间开销一次简单对比我先写一个测试脚本分别用列表推导式、生成器表达式、以及手动实现的生成器函数求 1000 万个数平方和import time n 10_000_000 # 方式一列表 start time.time() lst [x * x for x in range(n)] s1 sum(lst) print(列表耗时:, time.time() - start) # 方式二生成器表达式 start time.time() s2 sum(x * x for x in range(n)) print(生成器表达式耗时:, time.time() - start) # 方式三生成器函数 def square_gen(n): for x in range(n): yield x * x start time.time() s3 sum(square_gen(n)) print(生成器函数耗时:, time.time() - start)从我的实测结果看数据量一千万列表推导式因为要分配一个庞大的列表对象耗时约 1.5 秒左右内存占用几百 MB生成器表达式和生成器函数耗时约为 0.8 秒到 1.0 秒内存占用几乎可以忽略。生成器方案不仅省内存在求和这类单遍迭代场景下还更快因为省去了列表构建和元素搬运的开销。但事情要分两面看。如果后续需要反复多次访问同一批数据比如要遍历同一列表 20 遍做聚合生成器就不合适了因为生成器只能单向迭代一次。这种情况下一次性构建列表虽然首次耗时高但后续访问的时间复杂度是 O(1) 的索引总开销反而更优。4.2 工程选型标准一张表快速判断我把经验整理成一条简单决策链。先问自己几个问题数据总量是否非常大甚至无法完整放入内存如果是走生成器。数据是否会无限产生如果是只能走生成器。我是否只遍历一次、且顺序无关如果是生成器很合适。我需要随机访问中间元素吗比如data[5000]如果需要生成器不行得用列表。我需要反复多次遍历同一份数据吗如果遍历次数多、数据可重放可以重新创建生成器或用列表缓存。场景推荐方案原因超大文件逐行处理生成器内存恒定无限序列生成生成器列表无法表示无限单遍聚合计算求和/统计生成器或生成器表达式省内存且速度快需要索引随机访问列表 / 元组生成器无下标访问小数据量多次复用列表构建开销低使用便捷数据管道链式清洗多个生成器串联代码简洁、内存效率高放到业务里判断时我的默认经验是数据规模超过内存可用空间的 20% 时立刻改用生成器流式计算。如果数据只是几千条用列表推导式无可厚非别为了“优雅”而把所有代码都改成生成器过度设计也是一种负担。补充一句关于迭代器与生成器的区别。迭代器是一个更宽泛的概念只要实现了__iter__()和__next__()方法的对象都是迭代器生成器函数产生的对象是迭代器的一种具体实现。平时你可以把生成器当成一种“自动化了”的迭代器——不需要手动定义类、写__next__只要写 yield 就完事。5. 避坑手册那些年我踩过的生成器问题5.1 五个高频报错与多年的细节问题一生成器没有长度不能 len()我第一次对生成器执行len(gen)时直接报错TypeError: object of type generator has no len()。生成器是“未知长度”的流可能无限所以 Python 根本不允许求长度。如果你想知道剩余数量只能遍历计数或者提前用列表装下再 len。问题二生成器只能遍历一次生成器不是可重放的磁带而是单向的自来水管。第一次 for 循环取出所有元素后生成器就空了第二次循环什么也拿不到。gen (x for x in range(5)) print(list(gen)) # [0, 1, 2, 3, 4] print(list(gen)) # []应对办法是如果需要反复遍历每次重新调用生成器函数创建新的生成器对象def data_gen(): yield from range(5) for x in data_gen(): pass for x in data_gen(): # 每次调用都是新对象 pass问题三return 的值不在迭代中出现生成器函数里可以写return它起到“结束迭代”的作用但返回的值不会出现在迭代序列里而是被包装在StopIteration异常的 value 属性中。def gen_with_return(): yield 1 yield 2 return done捕获规则是这样的g gen_with_return() try: while True: print(next(g)) except StopIteration as e: print(返回值:, e.value) # done如果你的 Python 版本在 3.7 之后for 循环对 StopIteration 做了特殊处理看不到这个 “done”只有手动调用 next 时才能捕获到。这一点很容易被忽略。问题四在生成器里分配超大列表有些新手把生成器函数当作普通列表的替代却仍然在函数内部构建了一个大列表def bad_gen(n): data [i * i for i in range(n)] # 又回到一次性构建 for item in data: yield item这样内存问题完全没得到解决只是把压力后移了。正确的做法是把列表推导式也写成生成器表达式的形式或者直接在 yield 前不暂存。问题五无限递归导致递归深度溢出递归生成器虽然好用但无限递归会像普通函数一样触发RecursionError。用yield from展开无限子节点时必须要设置终止条件避免递归层数过多。5.2 一条实用的调试技巧给生成器加“日志”生成器太抽象出错时最难判断执行到哪里。我的习惯是借助打印日志来追踪比如写一个小包装器def debug_wrapper(gen): for item in gen: print(f[debug] 产出: {item}) yield item把任何一个生成器传进 debug_wrapper就能在运行时看到数据流经过的每个元素。特别是多个生成器串联时在某一环插入 debug_wrapper能迅速定位是上游不出数还是下游吞了数据。另外一个好用的官方工具是inspect.getgeneratorstate()它能告诉你生成器当前处于GEN_CREATED、GEN_SUSPENDED、GEN_RUNNING还是GEN_CLOSED状态。调试协程卡住时很有参考价值。5.3 把生成器组合成数据管道这里分享一个让我受用很久的技巧灵活使用itertools.chain把多个生成器合并成一个连续流。from itertools import chain def read_file_a(): yield a1 yield a2 def read_file_b(): yield b1 for line in chain(read_file_a(), read_file_b()): print(line) # a1, a2, b1这种方式在合并多个数据源时特别清爽整个程序从“一堆循环”变成“一条流水线”。再配合itertools.groupby、itertools.filterfalse这些函数你可以搭建出很强大的数据处理编排链路而不用为每个临时结果专门建列表。6. 写在最后惰性求值不仅是语法更是思维习惯如果只能说一句经验我会说在你写任何“先构建整个序列再从头遍历”的代码之前多想一秒钟——这个序列是否真的需要一次性完整存在于内存里如果答案是否定的那么生成器就是更优雅的选择。它不是 Python 里最酷炫的语法但却是“避免内存灾难”和“构建高效数据管道”的利器。当你习惯了用生成器的思维去写代码你会发现很多大流量、大数据量场景下的性能问题根本还没到需要上分布式框架的地步单机加生成器就已经能轻松扛住了。