生成器不会自动泄漏内存，但丢弃未耗尽的生成器会导致帧栈悬停、局部变量滞留和内存缓慢上涨；应显式调用close()、强制耗尽或用上下文管理器确保清理。
生成器函数本身不会自动泄漏内存，但一旦外部调用方丢失对它的控制（比如没调用 next()、没遍历完就丢弃、或未处理 StopIteration），其内部帧栈（gi_frame）和局部变量就会被悬停持有——这不是 GC 失效，而是 Python 保留运行上下文以支持可能的恢复，结果就是协程式堆积和内存缓慢上涨。
识别悬停生成器的典型信号
这类泄漏往往隐蔽：内存随请求量线性增长，但 gc.get_objects() 看不到明显异常对象。关键检查点是：
- 调用
sys.getsizeof(gen)发现单个生成器实例占用远超预期（如 >10KB），说明帧栈中残留大量数据 - 用
gen.gi_frame.f_locals查看局部变量，常发现缓存字典、大列表或数据库连接未释放 - 统计存活生成器数量：
sum(1 for obj in gc.get_objects() if hasattr(obj, 'gi_frame') and obj.gi_frame)，若持续增长且不归零，即存在悬停
避免丢弃前未耗尽的常见场景
很多逻辑误以为“不迭代 = 自动清理”，实际恰恰相反：
-
条件提前退出：例如
for item in gen: if item > 100: break，后续项永远不被取，生成器挂起 -
异常中断遍历：生成器内部抛出异常后，外部未捕获或未调用
gen.close()，帧栈锁死 -
赋值即丢弃：如
gen = my_generator(); some_func(gen)，而some_func仅检查类型却不消费 -
异步混用失配：把同步生成器传给
async for或await asyncio.to_thread()却没做适配，导致事件循环无法驱动 next
安全释放生成器的三类操作
不能只靠 GC 等待，必须主动干预：
-
显式关闭：在确定不再需要时调用
gen.close()，它会触发GeneratorExit异常，让生成器有机会清理资源（如关闭文件、断开连接） -
强制耗尽：对可信来源的生成器，可用
collections.deque(gen, maxlen=0)零开销取完所有项，比list(gen)更省内存 -
上下文封装：自定义
contextlib.contextmanager包裹生成器，在__exit__中确保close()被调用，尤其适用于带资源管理的生成器
设计层面的预防建议
从源头减少悬停风险比事后修复更有效：
- 生成器函数内避免持有大对象引用；局部变量尽量轻量，敏感资源（如 DB cursor）用
try/finally保证释放 - 对外暴露时优先返回迭代器而非生成器对象，或包装为
itertools.islice(gen, max_items)加硬限制 - 在关键路径加健康检查：定期扫描
gc.get_objects()中未关闭的生成器，记录其gi_code.co_name和gi_frame.f_lineno定位源头 - 禁用无意义的生成器链式调用，如
filter(..., map(..., gen))嵌套过深，易造成多层帧栈滞留
