生成器表达式支持流式处理，而列表推导式不支持；前者内存恒定O(1)、低延迟、可链式惰性计算，后者需全部加载、内存O(n)、易OOM。
(x for x in ...) 能在数据还没全部到达时就开始处理，而 [x for x in ...] 必须等所有输入就绪才返回结果——这是流式处理不可妥协的前提。
生成器表达式天然支持“边来边算”
流式处理的核心是低延迟、恒定内存、不阻塞。生成器表达式返回的是一个迭代器对象，它不保存数据，只保存计算状态（比如当前 range 的位置、局部变量值），每次 next() 才触发一次计算。
- 适合读取网络响应流、大文件逐行、传感器实时数据：数据源本身是逐步产出的，生成器能立刻接住第一项并开始处理
- 列表推导式会卡在
open('10GB.log')后面等整个文件读完、再等全部line.strip()完成，才返回列表——这在流场景里根本不可接受 - 例如
(line for line in sys.stdin)可以立即响应用户键入的第一行，而[line for line in sys.stdin]会永远等待 EOF
内存占用从 O(n) 降到 O(1)，避免流式中途崩溃
处理 1 亿行日志时，列表推导式可能瞬间吃掉 8GB 内存；生成器表达式始终只占约 56 字节（一个 generator 对象本身的开销）。
- 实测：对
range(10**8)做平方，[x**2 for x in range(10**8)]触发MemoryError；(x**2 for x in range(10**8))创建零延迟 - 在 Kubernetes 中设了
memory limit=128Mi的 Pod 里，用生成器可稳定跑通 PB 级 ETL；换成列表推导式，worker 几乎必 OOM - 注意：不是“生成器更快”，而是“它让流式处理成为可能”——没有这个内存保障，整个链路就断了
链式组合时不堆积中间结果
流式处理常需多步转换（过滤→映射→聚合），生成器表达式可直接嵌套，每一步都只维持一个元素在内存中。
- 写法自然：
sum(x for x in (y*2 for y in data if y > 0))—— 三层逻辑全惰性，峰值内存 ≈ 单个整数大小 - 若用列表推导式：
sum([y*2 for y in [x for x in data if x > 0]])，会先建两个完整中间列表，内存翻倍 - 和
itertools配合更稳：itertools.islice(gen, 1000)可安全截取前 1000 项，不用怕源数据无限长
容易踩的坑：一次性 + 无索引 = 设计约束必须遵守
生成器不是“轻量列表”，它是有严格行为契约的迭代器。忽略这点会导致静默错误或重复逻辑。
立即学习“Python免费学习笔记（深入）”；
- 只能遍历一次：用完即空，再次
for或list()会得到空结果；需要重用就得重新创建，或显式转成list（但那就失去流式意义） - 不支持
len()、gen[5]、gen[::-1]—— 这些操作本身与流式理念冲突，强行加会破坏惰性 - 调试时别直接
print(gen)，看到<generator object ...>是正常的；要观察内容得用next(gen)或list(itertools.islice(gen, 5))
