生成器表达式内存极小（约56–120字节），列表推导式则需分配全部元素内存（如百万项约8mb）；其省内存优势仅在惰性使用（如for遍历、sum等一次性消费）时成立，一旦转为list或被多次遍历即失效。
生成器表达式创建时不分配元素内存
生成器表达式 (x*2 for x in range(10**6)) 本身只是一个迭代器对象，只存当前状态（如循环变量、代码指针），sys.getsizeof() 实测约 56–120 字节；而列表推导式 [x*2 for x in range(10**6)] 会立刻在堆上分配连续空间，存储全部一百万个整数，CPython 中每个 int 占 24–28 字节，加上列表结构开销，总内存约 8MB。
这个差异不是理论估算——你运行 sys.getsizeof([x for x in range(100000)]) 和 sys.getsizeof((x for x in range(100000))) 就能直接看到数字。
真正省内存的前提是“不全取出来”
生成器省内存的条件非常具体：你得让它保持惰性，只用 for 遍历、next() 取前几个、或传给 sum()/any()/max() 这类一次性消费函数。
- ✅ 正确：
sum(x*2 for x in range(10**6))—— 元素边算边加，峰值内存≈生成器对象 + 一个整数 - ❌ 错误：
list(x*2 for x in range(10**6))—— 先建生成器（+56B），再建新列表（+8MB），GC 前峰值反而略高 - ⚠️ 隐蔽陷阱：
pandas.DataFrame(gen)或numpy.array(gen)会内部调用list(gen)，生成器优势完全消失
生成器不支持随机访问，但很多场景根本不需要
你不能对 gen 写 gen[5]、len(gen) 或 gen[::-1]，这不是缺陷，而是内存节省的必然代价：不存全部值，就无法回头或跳转。
常见误判场景：
- 以为“用括号就是懒”，结果又立刻
list(gen)调试——调试可以，但别留进生产逻辑 - 嵌套写成
((x,y) for x in A for y in B)，想print看中间结果，只能看到<generator object></generator>，没法 inspect - 闭包捕获变量出错：
(lambda: i for i in range(3))全部返回i=2，和列表推导式行为一致，但更难断点追踪
性能差异取决于使用链，不是单看创建耗时
测 timeit 时，只比 [x**2 for x in range(n)] 和 (x**2 for x in range(n)) 的构造时间毫无意义——后者几乎为 0，但后续迭代才是关键。
实测有效对比方式是测完整使用链：
- ✅ 单次遍历：
sum(x**2 for x in range(10**7))通常比sum([x**2 for x in range(10**7)])快且内存低，因避免了中间列表分配与 GC 压力 - ❌ 多次遍历：如果之后还要
sorted(gen)、gen[100]、再for x in gen:一遍，必须用列表，否则第二次遍历就空了 - ⚠️ 函数参数陷阱：
map(func, (x for x in data))是惰性的，但map(func, list(data))已经全加载——注意函数是否内部强制转 list
最常被忽略的一点：生成器对象本身轻量，但一旦被消费完，就不可重用；而列表可反复读、切片、传给任何库——选哪个，本质是在“内存/速度”和“灵活性/可重用性”之间做显式权衡。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
