python对含__del__的循环引用主动放弃回收，将其放入gc.garbage；gc仅跟踪可变容器，不可变对象不参与；分代回收机制下gc.collect()返回0未必失败，需警惕隐式强引用导致的内存泄漏。
带 __del__ 的类实例参与循环引用时，GC 直接跳过回收
不是“无效”，而是 Python 主动放弃回收——只要任意一个对象定义了 __del__ 方法，且它处于循环引用中，gc.collect() 就不会清理整个环。原因很实际：无法安全决定析构顺序。比如 a.__del__() 可能要访问 b.x，但若 b 已先被销毁，就会触发异常或崩溃。
此时 GC 会把这类对象放进 gc.garbage 列表（一个未处理的不可达对象容器），而不是直接释放内存。
-
gc.garbage默认为空；一旦出现带__del__的不可达循环，对象就滞留在此列表中，不自动清理 - 手动调用
gc.collect()后检查len(gc.garbage)，能确认是否卡住 - 即使后续删掉所有外部变量，只要
gc.garbage非空，那些对象就一直占着内存
gc 模块本身不管理所有对象，只跟踪“可变容器”
Python 的 gc 模块只对可能形成引用环的对象启用跟踪，比如 list、dict、自定义类实例；而 int、str、tuple（不含可变元素时）等不可变类型压根不进 GC 队列，全靠引用计数。
所以如果你的“类”里只存 int 和 str，又没和任何容器型对象互指，那根本不会触发循环检测——这不是 GC 失效，是它压根没介入。
- 用
gc.is_tracked(obj)可查某个实例是否在 GC 管理范围内 - 自定义类若继承了
object（默认），且含可变字段（如self.data = []），通常会被自动跟踪 - 若类中全是不可变属性，或显式调用了
gc.untrack(self)，GC 就看不见它
手动触发 gc.collect() 也不保证立即回收循环引用
GC 是分代的：新对象在第 0 代，只有当该代对象数量超过阈值（默认 700），才会触发扫描。即使你刚构造完循环并 del 所有外部变量，若还没到阈值，gc.collect() 可能返回 0 —— 不是失败，是“还没轮到扫”。
- 强制清理第 0 代：
gc.collect(0)，比gc.collect()更快响应小循环 - 查看当前阈值：
gc.get_threshold()，三个数分别对应 0/1/2 代触发条件 - 调用
gc.collect()返回值是本次回收的对象数，为 0 不代表没循环，可能只是没触发扫描
真正该警惕的不是“GC 不工作”，而是“对象本不该长期存活却滞留”
循环引用本身不是问题，CPython 能稳稳扛住；出问题的是那些本该随函数退出或作用域结束就消失的大对象（比如缓存字典、数据库连接包装器、GUI 控件树），因为隐式循环一直挂着，导致内存缓慢上涨。
这时候别急着调 gc.collect()，先用 gc.get_referrers(obj) 追一下谁还在强引用它——90% 的泄漏源头是意外保留的全局 dict、闭包变量或信号槽绑定。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
