列表推导式会一次性将所有结果加载进内存，导致内存溢出；应改用生成器表达式（圆括号），实现惰性求值、O(1)内存占用，并配合sum()、max()等函数直接消费。
大列表推导式为什么突然吃光内存？
因为列表推导式 [x for x in iterable] 会一次性把所有结果加载进内存，哪怕 iterable 是一个百万级的文件行生成器或数据库游标。Python 不会“懒”——它直接构造完整 list 对象，中间不释放、不暂停。
常见错误现象：MemoryError、系统变卡、进程被 OOM killer 杀掉；而你只是想逐条处理数据，根本不需要全量存下来。
- 使用场景：读大文件、处理 API 分页响应、迭代数据库查询结果、做流式数据清洗
- 关键区别：你要的是“能遍历”，不是“能随机索引”——那就不该用
list - 性能影响：内存占用从 O(n) 降到 O(1)，GC 压力大幅降低
用生成器表达式替代列表推导式
只需把方括号换成圆括号：[x*2 for x in range(10**6)] → (x*2 for x in range(10**6))。它返回一个生成器对象，每次调用 next() 才计算一个值，不缓存历史结果。
注意：生成器只能遍历一次，且不支持 len()、index()、切片等操作——这反而是好事，说明你没误用它当列表用。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 如果后续要多次遍历，先明确是否真需要——多数情况其实只需要一次
for或传给sum()/any()等消耗型函数 - 若必须多次用，且数据可重放，就重新创建生成器；否则才考虑转成
list（但请确认容量可控） - 兼容性无问题：所有 Python 3.x 都支持，语法层级替换，无需额外依赖
配合 itertools 和内置函数进一步降压
很多常见聚合操作根本不需要中间列表。比如求和、找最大值、判断是否存在——直接喂生成器给对应函数即可，它们内部是逐个消费的。
示例：sum(x**2 for x in data) 比 sum([x**2 for x in data]) 内存友好得多；max(data, key=lambda x: x.score) 也比先 sorted(..., key=...)[0] 强得多。
-
itertools.islice(gen, n)取前 n 项，不展开整个生成器 -
itertools.chain(a, b)合并多个生成器，仍保持惰性 - 避免
list(gen)或tuple(gen)—— 这等于又回到原点
警惕“伪装成生成器”的陷阱
有些写法看起来像生成器，实则暗中构建了大结构。最典型的是字典推导式 {k: v for k, v in items} 和集合推导式 {x for x in seq}，它们仍是立即求值、全量入内存的。
另一个坑是嵌套推导式：[[y for y in x] for x in matrix] 会生成完整二维列表；若只需扁平化，改用 (y for x in matrix for y in x)。
- 第三方库如
pandas.read_csv(..., chunksize=)返回的是可迭代的TextFileReader，别误写成list(reader) - 用
sys.getsizeof()测试小样本，确认对象大小是否随输入线性增长 - 真正难的是思维切换：从“我要一个容器”转向“我只要一个流程”
