该用列表推导[…]当需多次遍历、索引、切片或长度；生成器推导(…)适用于单次消耗、大数据量、省内存场景，但不可pickle、不支持随机访问。
什么时候该用 [...] 而不是 (...)
列表推导 [x for x in iterable] 立即生成全部元素并存入内存；生成器推导 (x for x in iterable) 只返回一个迭代器，每次取值才计算。关键看你要不要「多次遍历」或「随机访问」。
- 需要索引（如
result[0]）、切片（result[:5]）、长度（len(result)）→ 必须用列表推导 - 只遍历一次、且数据量大（比如处理上万行日志）→ 优先用生成器推导，省内存
- 传给
sum()、max()、any()这类一次性消耗迭代器的函数 → 两者都行，但生成器更轻量
list(...) 包裹生成器推导等于白忙活
写成 list(x for x in range(1000000)) 和直接写 [x for x in range(1000000)] 效果一样：全量构造、吃光内存。这不是“用生成器优化”，只是多套了一层括号。
- 如果真想节省内存，就别调
list()，直接把生成器传给目标函数（比如process_data((x*2 for x in data))） - 调试时想看内容？用
list(gen)没问题，但上线代码里留着它，等于放弃生成器优势 - 常见误写：
return (x for x in items if x > 0)被调用方又立刻list(...)→ 不如一开始就用列表推导，语义更直白
嵌套推导里括号容易错配
生成器推导必须用圆括号，但函数调用本身也用圆括号，嵌套时极易漏掉最外层或混淆层级。错误示例：sum(x*2 for x in data if x > 0) 是对的；而 sum((x*2 for x in data) if x > 0) 会报 NameError: name 'x' is not defined —— 因为 if 跑到生成器外面去了。
- 生成器推导的
if必须紧跟在for后面，不能放在外层表达式里 - 多层
for时，括号不解决可读性问题，比如(x+y for x in a for y in b if x != y)，建议拆成普通for循环 - 列表推导允许省略外层括号（如函数参数内），但生成器推导不行：
func(x for x in a)合法，func(x for x in a, y for y in b)语法错误 —— 缺少元组括号
生成器推导无法被 pickle 或跨进程传递
如果你用 multiprocessing 或 joblib 并行处理，把生成器推导对象传进子进程会失败，报 TypeError: can't pickle generator objects。列表就没这问题。
立即学习“Python免费学习笔记（深入）”；
- 不是所有“惰性”都适合分布式或并发场景；需要共享数据时，老实用列表
- 想兼顾惰性和可序列化？考虑
itertools.chain或自定义类实现__getstate__，但多数情况直接转list更省心 - 调试时用
print(type(gen))确认是<class></class>而非<class></class>，避免以为用了生成器实则已被展开
生成器推导的真正价值不在“看起来高级”，而在明确表达「我只要一遍、不存全量、别给我内存」——一旦这个前提被打破，它就只是个带括号的语法糖。