gc.collect()仅处理循环引用，对普通对象堆积无效；低内存时应优先砍引用、清容器、关自动回收，并用gc.collect(0)分级回收，避免全量stop-the-world。
gc.collect() 在低内存环境里基本没用
它只处理循环引用，而低内存问题绝大多数来自普通对象堆积（比如缓存没清、日志对象塞满列表、大文件读入后没 del）。调用 gc.collect() 不会释放这些对象——引用计数不为 0，GC 根本不碰它们。
真正有效的动作是：砍引用、清容器、关自动回收干扰诊断。手动 GC 只在确认存在循环引用且影响稳定时才作为兜底手段。
先确认是不是真有循环引用残留
别一内存涨就 gc.collect()，先用工具定位谁卡着内存：
-
gc.disable()临时关掉自动回收，避免干扰观察 - 构造疑似问题场景后，立刻调用
gc.collect(0) - 检查
gc.garbage是否非空——非空说明有未清理的循环引用对象留在里面 - 更直接：用
gc.get_referrers(obj)查谁还拿着obj；用gc.get_referents(obj)查obj自己又拽着谁
常见“隐形引用源”：logging.Logger 的上下文、模块级字典、threading.local()、__dict__ 动态赋值、装饰器闭包里捕获的大对象。
低内存下该用哪一档 collect
全量回收（gc.collect() 无参数）会 Stop-The-World，可能让服务超时。生产环境必须分级控制：
-
gc.collect(0)：只扫最新一批对象，开销最小，适合刚解析完 JSON 或构建完树结构后快速清理 -
gc.collect(1)：0 代 + 部分 1 代，折中选择，可用于批处理中间点 -
gc.collect(2)：强制全代扫描，暂停整个解释器，仅限 OOM 前最后抢救，日常禁用
注意：gc.collect() 返回值是清理掉的不可达对象数量，不是释放的字节数——它不告诉你省了多少内存，只告诉你“理论上该清的循环引用清掉了几个”。
比 gc.collect() 更关键的三件事
GC 是兜底，不是开关。低内存稳定性取决于你主动管理引用的能力：
- 大对象处理完立刻
obj = None或del obj，尤其numpy.ndarray、pandas.DataFrame、大字符串 - 缓存类结构必须显式清理：
cache.clear()、del cache[key]，别等 GC - 对可能形成环的结构，优先用
weakref.WeakValueDictionary或weakref.ref()替代强引用
最常被忽略的一点：gc 模块本身在低内存下也可能失效——如果对象带 __del__ 方法，GC 会跳过回收，防止析构顺序冲突。这种情况下，手动打破引用链是唯一出路。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
