生成器转成 list 会丢掉流式优势，别这么干
生成器本质是「按需产出」的迭代器，一旦用 list(gen) 强制展开，就全量加载进内存，彻底失去流式处理意义。尤其面对大文件、数据库游标或网络响应流时，list() 可能直接 OOM。
真正需要的不是“转换”，而是让生成器参与后续流式链路——比如传给 itertools 工具函数、喂给 pandas 的 read_csv() 迭代接口、或作为异步任务的输入源。
- 用
itertools.islice(gen, 1000)截取前 N 项，不触发后续计算 - 用
itertools.chain(gen1, gen2)合并多个生成器，仍保持惰性 - 避免任何显式收集操作（
list()、tuple()、[x for x in gen]）
用 generator expression 替代中间 list 提升性能
常见错误是先用列表推导生成临时 list，再转成生成器：比如 gen = (x for x in [f() for f in funcs])。这里 [f() for f in funcs] 已经执行全部调用并占内存。
正确做法是把逻辑直接写进生成器表达式里，让调用延迟到迭代时：
立即学习“Python免费学习笔记（深入）”；
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
# ❌ 错误：先全量执行再包装 funcs = [lambda: expensive_io(), lambda: another_call()] temp_list = [f() for f in funcs] # 此刻已全部执行 gen = (x for x in temp_list) <h1>✅ 正确：只在 next() 时才调用</h1><p>gen = (f() for f in funcs) # funcs 里的函数尚未执行
- 检查生成器内部是否有提前求值的表达式（如列表推导、函数调用、IO 操作）
- 用
inspect.isgeneratorfunction()验证函数是否真返回生成器，而非返回 list 后被误当生成器 - 生成器表达式比等价的
def函数更轻量，但调试困难；复杂逻辑建议用yield显式函数
对接 pandas 或 numpy 时别强行转成 list
pandas 的 read_csv()、concat() 和 numpy 的 fromiter() 都原生支持生成器，但参数和行为差异大：
-
pandas.read_csv('file.csv', chunksize=1000)返回的是TextFileReader（可迭代对象），不是生成器，但效果类似；直接 for 循环即可 -
pd.concat([chunk for chunk in reader], ignore_index=True)是反模式 —— 应改用pd.concat(reader, ignore_index=True)，pandas 内部会逐个迭代 -
np.fromiter(gen, dtype=float, count=-1)要求生成器产出同类型数据，且count=-1表示长度未知；若知道长度，设具体值能预分配内存，提速明显
生成器无法重复迭代，这是设计特性不是 bug
生成器耗尽后再次迭代会立刻返回空结果，不会报错也不会重放。这常导致「第一次 for 循环正常，第二次啥也不输出」的困惑。
如果你确实需要多次使用同一数据流，有且仅有两种合法方式：
- 重新创建生成器：比如封装成函数
def data_stream(): yield ...，每次调用data_stream()得到新实例 - 用
itertools.tee(gen, n)分叉出 n 个独立迭代器，但注意：所有分支共享底层缓存，第一个分支走得多，其余分支就得等它；内存占用随最慢分支滞后增长 - 绝对不要用
list(gen)然后反复遍历 list —— 这等于放弃流式初衷，还多一次内存拷贝
真正高性能的数据流结构，不是「把生成器变成别的东西」，而是让整个处理链路保持惰性、按需、单次消费。卡在这里的，往往不是语法问题，而是对「流」和「集合」的思维混淆。
