gc.collect()后对象仍在gc.garbage中，说明它被判定为不可回收的循环引用；需先启用gc.debug_saveall，再调用gc.collect()触发保存，且gc.garbage需手动清空以防累积。
gc.collect() 后对象还在 gc.garbage 里，说明它被判定为不可回收的循环引用
Python 的 gc 模块默认不暴露循环引用细节，但一旦你调用 gc.collect()，所有“疑似无法回收”的对象会被塞进 gc.garbage 列表（前提是之前启用了 gc.DEBUG_SAVEALL 或对象确实卡在了 gc 链表中）。这不是 bug，是设计行为：只有被 gc 跟踪的容器对象（如 list、dict、自定义类实例）才可能进这里；int、str 等原子类型根本不会被追踪，也不可能形成循环引用。
实操建议：
- 先执行
import gc; gc.set_debug(gc.DEBUG_SAVEALL)，再复现可疑操作，最后调用gc.collect() - 检查
gc.garbage是否非空：if gc.garbage: print(gc.garbage) - 注意：
gc.garbage是个普通 list，每次gc.collect()后它不会自动清空，得手动清掉（del gc.garbage[:]）否则会累积 - 如果
gc.garbage为空，不代表没循环引用——可能已被分代回收提前清理，或对象压根没被gc跟踪（比如只含字符串的 tuple）
用 gc.get_referrers() 追源头时，别把方向搞反了
gc.get_referrers(obj) 返回的是“谁引用了 obj”，不是“obj 引用了谁”。新手常误以为这是查引用链下游，结果一层层往下追，越追越偏。正确做法是：从疑似泄漏对象出发，向上查它的直接持有者，再逐级往上，直到找到外部变量或模块级引用。
常见干扰项必须过滤：
- 返回结果里大量出现
frame对象（函数栈帧），通常是临时变量或调试残留，加条件not isinstance(r, types.FrameType)排掉 -
module、gc.garbage、__main__这些也优先跳过，它们不是业务逻辑里的“持有者” - 若某次调用返回空列表，说明该对象已无强引用——但它可能还活着（比如被弱引用间接保活，或刚被
del但还没触发__del__）
对比 gc.get_objects() 快照比对，比单看 refcount 更可靠
sys.getrefcount(obj) 看似直观，但传参本身会让计数 +1，结果永远比真实值大 1；而且对 C 扩展对象或某些内置类型（如 datetime）可能返回异常高值，不能当真。更稳的方式是做两次 gc.get_objects() 快照，取差集找新增对象。
关键步骤：
- 确保单线程运行，避免并发干扰快照一致性
- 操作前记录：
before = {id(o) for o in gc.get_objects()} - 操作后记录：
after = {id(o) for o in gc.get_objects()} - 筛选
leaked = after - before，再对每个oid查sys.getrefcount()和gc.get_referrers() - 若某个对象
sys.getrefcount()> 3 且gc.get_referrers()返回多个业务相关对象（比如你的CacheManager实例和一个闭包），基本可锁定循环路径
weakref 不是开关，用错反而让问题更隐蔽
看到循环引用第一反应是“上 weakref”，但这是高风险操作。weakref.ref(obj)() 每次调用都要检查对象是否存活，性能比直接访问慢 3–5 倍；而 weakref.WeakKeyDictionary 的 key 会随时消失，若业务逻辑依赖 key 存在，就会出 KeyError 或静默失败。
真正该用弱引用的场景很窄：
- 父子关系中“子不控制父生命周期”：比如事件监听器注册到父对象，子对象销毁时监听器应自动失效
- 缓存类结构：用
WeakValueDictionary缓存计算结果，避免因缓存拖住大对象 - 绝对不要用在异步回调上下文、数据库连接池、或任何需要确保对象存活到某段逻辑结束的地方
最易被忽略的一点：即使用了 weakref，也要确认它没被塞进强引用容器里——比如把 weakref.ref(obj) append 到一个全局 list 却忘了清理，等于又造了个强引用环。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
