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 却忘了清理，等于又造了个强引用环。