生成器表达式省内存仅在惰性求值且不全消费时成立；一旦全转为列表，内存峰值与列表推导式相当，且不支持索引、长度查询和重复遍历。
生成器表达式只存状态，列表推导式直接存全部值
生成器表达式 (x*2 for x in range(10**6)) 创建的是一个迭代器对象，内部只保存当前迭代位置、循环变量引用和代码逻辑，实测占用约 56–120 字节；而列表推导式 [x*2 for x in range(10**6)] 会立刻在内存中分配连续空间存储一百万个整数，CPython 下每个 int 占 24–28 字节，加上列表结构开销，总内存约 8MB。这个差异不是估算，sys.getsizeof() 可直接验证。
惰性求值不等于“永远不占内存”，关键看是否被消费
生成器省内存的前提是你没把它一次性全取出来。一旦执行 list(gen)、sum(gen) 或 for x in gen: 走完全部迭代，内存峰值其实和列表推导式接近——因为目标容器（如新列表）正在构建，而生成器对象还活着，两者短暂共存。此时生成器反而多占几十字节，纯属冗余开销。
- 只取前 3 个：
next(gen); next(gen); next(gen)→ 内存几乎无增长 - 取全部：
list(gen)→ 先建生成器（≈56B），再建列表（≈8MB），GC 前峰值 ≈8MB+56B - 原地建列表：
[x*2 for x in range(10**6)]→ 直接分配 ≈8MB，无额外对象
生成器不支持随机访问，但也不是所有场景都需要
你不能对 gen 写 gen[5]、len(gen) 或切片，它只支持单次顺序遍历。这看似是限制，实则是内存节省的代价交换：不存全部值，就无法回头或跳转。如果你后续要多次用同一份数据做排序、索引、传给 pandas.DataFrame() 或 numpy.array()，它们内部都会强制转成 list/array，生成器不会帮你省哪怕一丁点内存。
- 适合：逐行读大日志文件、找第一个匹配项（
next(filter(...))）、管道式过滤转换 - 不适合：需要
my_data[1000]、my_data[::-1]、反复 for 循环、传给要求__len__的库函数
嵌套和闭包里容易踩坑，调试时看不见内容
生成器表达式在调试时非常不友好：print(gen) 只输出类似 <generator object> at 0x...></generator>，没法像列表那样一眼看到内容。更隐蔽的问题是闭包捕获——(lambda: i for i in range(3)) 中所有 lambda 都返回最后一个 i 值（2），和列表推导式里的行为一致，但生成器更难 inspect 和断点追踪。
立即学习“Python免费学习笔记（深入）”；
- 嵌套生成器如
((x,y) for x in A for y in B)无法直接print查看中间态 - 多层
itertools.chain()+ 生成器后，StopIteration错误堆栈可能指向最外层，源头早已耗尽 - 想临时转成列表调试？可以，但记得这只是调试手段，别留在生产逻辑里
() 还是 []，而是你是否保留了全部中间状态。生成器不是自动优化开关，它只在数据流能“流起来”的时候才生效——比如你提前 break、用 any() 判断存在性、或只处理前 N 条记录。否则，它只是把内存分配从“一开始”推迟到“用到时”，总量没变。 
