内存泄漏主因是循环中持续创建对象、缓存未清理或误用可变对象，而非for语法本身；常见问题包括全局列表累积、readlines()全量加载、pandas临时DataFrame堆积、生成器误转列表或重复遍历。
因为循环中持续创建新对象、缓存未清理、或误用可变对象导致引用无法释放，而不是for本身在“吃内存”。
循环里不断追加列表元素却不清理
这是最常见也最容易被忽略的内存增长点。每次 append() 都新增一个对象引用，而如果这个列表是全局变量、类属性或闭包内长期存活的变量，GC 就无法回收它。
- 错误写法：
results = []放在函数外，循环内反复results.append(...) - 正确做法：把
results移到函数内部；或处理完立刻del results+gc.collect()（仅当确认需要） - 更优解：用生成器替代收集——比如把
[process(x) for x in data]换成(process(x) for x in data)，边算边传，不囤积
读取大文件时用 readlines() 而非逐行迭代
readlines() 会一次性把整个文件所有行加载进内存，生成一个超长列表；而文件对象本身是可迭代的，for line in f: 是惰性读取，只保留当前行。
- 高风险操作：
lines = f.readlines()（GB 级文本直接 OOM） - 安全做法：
for line in f:或itertools.islice(f, chunk_size)分块处理 - 注意：
f.seek(0)后再循环，不会自动清空已读内容——文件对象内部状态只是指针移动，但readlines()的结果仍驻留在变量里
使用 pandas 或 numpy 时未释放中间 DataFrame
链式操作如 df[cond].groupby(...).agg(...) 表面上是一行，背后可能产生多个临时 DataFrame，尤其在循环中重复执行时，旧对象若被隐式引用（比如赋值给没清空的变量、或塞进字典），就会堆积。
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
立即学习“Python免费学习笔记（深入）”；
- 典型陷阱：
all_results[key] = df.groupby('x').sum()—— 字典一直持有引用，越积越多 - 缓解方式：显式
del df、用df.copy(deep=False)控制拷贝粒度、或改用pd.concat([...], ignore_index=True)替代累积字典 - 关键提醒：
gc.collect()对 pandas 对象效果有限，真正要删的是你代码里那些变量名，不是靠 GC “猜”哪些能删
生成器被意外转成列表，或多次遍历耗尽后还试图重用
生成器只能遍历一次，但很多人会无意识地把它转成列表（比如传给 len()、list()、sorted()），或在循环里反复调用同一个生成器对象。
- 危险模式：
data_gen = (x*2 for x in range(10**6)); print(len(list(data_gen)))—— 先转列表，再求长度，内存翻倍 - 更隐蔽的坑：
for x in data_gen: ...之后，再写for y in data_gen:，第二轮什么也不会执行，但你可能误以为逻辑没走，又补了一堆数据结构 - 解决思路：明确区分“数据源”和“消费动作”；需要多次遍历就用元组/列表；只消费一次就用生成器+流式处理
真正让内存“停不下来”的，往往不是循环语法本身，而是你放在循环里的那几行赋值、追加、缓存和隐式引用——它们像细沙一样漏进内存池，等发现水位过高时，沙子已经沉底了。
