应优先用生成器表达式(x2 for x in data)替代列表推导式[x2 for x in data]以节省内存，其适用单次遍历、链式处理等场景，但需警惕隐式展开、二次迭代失效及中间层贪婪操作。
用生成器表达式替代列表推导式
当不需要一次性持有全部结果时，[x * 2 for x in data] 会立刻分配内存构建完整列表，而 (x * 2 for x in data) 只在迭代时逐个产出，内存占用恒定为 O(1)。常见错误是误以为「推导式」只能写成方括号形式，其实圆括号才是生成器的合法语法。
适用场景：后续只做单次遍历（如传给 sum()、any()、for 循环），或需要链式处理（如 filter() + map()）。
- 注意不能对生成器二次迭代——它是一次性对象，重复
list(gen)会得到空列表 - 调试时别直接
print(gen)，看到<generator object ...>是正常的，要用next(gen)或转为list(gen)（仅限小数据验证） - 如果原推导式含
if条件，生成器写法完全一致：(x for x in data if x > 0)
分块处理超长可迭代对象
即使改用生成器，若 data 是一个无界或极大迭代器（如逐行读大文件、数据库游标），下游函数仍可能因内部缓存导致内存飙升。这时需主动切分批次，避免「看似懒加载，实则被中间层吃光内存」。
例如 itertools.islice() 或手动控制 while True + itertools.islice() 是更稳妥的选择，比依赖第三方库的分页逻辑更轻量、可控。
立即学习“Python免费学习笔记（深入）”；
-
itertools.islice(data, 0, 1000)每次取 1000 项，处理完再取下一批，不预加载全部 - 避免把整个生成器传给
pandas.DataFrame()或numpy.array()—— 它们会强制转为 list 再构造，瞬间破功 - 若必须转成 NumPy 数组，优先用
np.fromiter(gen, dtype=float, count=n)，指定count能防止意外耗尽内存
警惕隐式展开和中间列表
看起来没写方括号，但某些操作仍会触发全量展开。典型例子：用 + 拼接多个生成器、在 sorted() 中传入生成器、或用 list.extend() 接收生成器。
sorted(x for x in data) 本质等价于 sorted(list(x for x in data))，因为 sorted() 必须先收集所有元素才能排序；同理，my_list += (x for x in data) 会强制展开右侧生成器。
- 排序需求强烈时，考虑外部排序工具（如
sort命令行）、或用heapq.merge()合并已排序的分块结果 - 想累积数据？用
collections.deque(maxlen=N)替代普通 list，避免无限增长 - 检查是否无意调用了
list()、tuple()、set()包裹生成器——这是最常被忽略的内存泄漏点
用 yield 自定义惰性管道
当生成器表达式无法满足逻辑复杂度（比如多层条件嵌套、状态维护、跨元素计算），硬塞进一行推导式反而难读易错。此时应退回到函数 + yield，显式控制产出时机。
例如实现「跳过前 N 个偶数，然后取接下来 M 个奇数」，用嵌套生成器极易混乱，而用带计数器的 yield 函数一目了然，且依然保持 O(1) 内存。
- 函数内
yield的性能与生成器表达式几乎无差异，Python 解释器对其有专门优化 - 避免在
yield函数里构建临时列表（如result = []; for ...: result.append(...); yield result）——这又回到了高内存模式 - 配合
itertools.chain()可组合多个yield函数，形成清晰的数据流，比嵌套推导式更易测试和复用
真正棘手的不是“怎么写生成器”，而是识别哪些地方表面惰性、实际贪婪——比如某个封装好的库函数接收迭代器，但内部偷偷调用了 len() 或 list()。遇到内存异常上涨，优先查文档、看源码、加断点确认是否被中间层强制展开。
