用生成器链代替列表推导式可节省内存、支持逻辑拆分与清晰调试。它逐个产出值，适合处理大文件；需注意迭代器单次消费、避免过早转列表、合理使用yield from及控制资源生命周期。
为什么用生成器链代替列表推导式处理大文件
因为内存不爆、逻辑可拆分、调试更清晰。列表推导式会一次性把全部结果加载进内存，而生成器管道每一步只产出一个值，适合处理 GB 级日志、CSV 或数据库游标结果。
常见错误是误以为 map() 或 filter() 返回的是列表——在 Python 3 中它们返回的是迭代器，但一旦被多次遍历（比如打印两次），第二次就空了。
- 用
itertools.tee()复制生成器仅当必须多路消费时，它会缓存已产出项，可能吃内存 - 避免在生成器函数里写
return list(...)，这等于废掉流式优势 - 调试时可用
itertools.islice(gen, 5)取前 5 个，而不是list(gen)[:5]
如何写出可组合的生成器函数
关键不是“能 yield”，而是参数设计要支持下游拼接。典型模式：第一个参数是输入迭代器，其余是配置参数；返回仍是生成器对象（即用 yield 或 yield from）。
比如清洗 CSV 行、转类型、过滤空值，每个环节都应接受一个迭代器并返回一个迭代器：
def parse_csv_lines(lines):
for line in lines:
yield line.strip().split(",")
def convert_types(rows, types=(str, int, float)):
for row in rows:
yield [t(v) for t, v in zip(types, row)]
def filter_nonempty(rows):
for row in rows:
if all(row):
yield row
这样就能串成：filter_nonempty(convert_types(parse_csv_lines(open("data.csv"))))。
- 不要在生成器内部做
open()或requests.get()—— 资源打开/关闭应由最外层控制 - 如果需要状态（如累计计数），用闭包或类封装，别依赖全局变量
- 传入的迭代器尽量不做
list()，除非明确知道数据量小且需随机访问
yield from 在管道中怎么用才不翻车
它本质是委托子生成器，让调用方直接从子生成器取值，省去一层 for ... yield 循环。但它不是万能的：不能用在非生成器对象上，也不能和普通 return 混用（Python 3.3+ 允许 return value，但该值只能被 StopIteration.value 捕获，不能被下游迭代到）。
典型误用：
-
yield from some_list没问题，但yield from some_function_that_returns_list()就危险——如果函数返回大列表，还是占内存 - 想中途终止委托？得用
try/except GeneratorExit，但一般不建议手动干预退出流程 - 嵌套太深（A → B → C → D）会让堆栈难追踪，建议单层深度不超过 3，复杂逻辑拆到独立函数里
性能陷阱：什么时候生成器反而更慢
小数据 + 高频调用时，生成器开销（帧对象创建、状态保存）可能比直接列表快不了多少，甚至更慢。尤其当每个 yield 只处理几个字符或数字时，函数调用成本占比过高。
实测常见场景对比：
- 读取 10MB 文件逐行处理 → 生成器快 3 倍，内存低 99%
- 对 1000 个整数做
abs(x) * 2→ 列表
推导式快 1.2 倍，生成器无明显优势 - 含正则匹配或 JSON 解析的管道 → 瓶颈在 CPU，生成器本身开销可忽略
推导式快 1.2 倍，生成器无明显优势真正影响吞吐的是 I/O 阻塞、序列化、外部 API 调用这些环节，生成器只是把它们“摊平”成流，别指望它自动提速。
容易被忽略的一点：生成器函数一旦被调用，返回的是生成器对象，但**不会执行任何代码**，直到第一次 next() 或进入 for 循环。这意味着错误（比如除零、键不存在）不会在构建管道时抛出，而是在消费时才暴露——调试时得留意这个延迟报错特性。
