gc.set_debug() 用于让 GC 在回收时输出诊断信息，关键组合是 gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS，避免误用 DEBUG_SAVEALL 导致内存上涨。
如何用 gc.set_debug() 捕获循环引用泄漏
Python 的 gc 模块默认不报告可疑对象，遇到内存缓慢增长却查不到源头时，gc.set_debug() 是最直接的切入点。它不是用来“开启 GC”，而是让 GC 在回收过程中输出诊断信息。
常见错误是只传 gc.DEBUG_STATS，结果只看到统计数字，漏掉关键的 UNCOLLECTABLE 或 COLLECTING 日志。真正有用的组合是：
-
gc.set_debug(gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)—— 触发时会打印无法回收的对象及其引用链片段 - 避免长期启用
DEBUG_SAVEALL，它会阻止 GC 清理所有不可达对象，导致内存持续上涨，仅用于瞬时抓取 - 日志输出到
sys.stderr，若用 IDE 或 notebook，需确认控制台是否捕获 stderr（例如 Jupyter 默认不显示）
gc.get_referrers() 查谁在持有你的对象
当你定位到一个疑似泄漏的对象（比如某个类实例或闭包），gc.get_referrers() 能快速反向追踪谁还引用着它。但要注意：它返回的是“直接引用者”，不是完整路径，且包含临时帧、字典项等干扰项。
- 先用
id(obj)记录目标对象 ID，再调用gc.get_referrers(obj)，避免对象被中途回收导致查无此物 - 过滤掉
frame对象（通常来自调试器或 traceback），重点看dict、list、模块级变量名 - 如果返回空列表，说明该对象已无强引用——此时可能是弱引用残留或 GC 尚未运行，需手动触发
gc.collect() - 慎用在多线程环境：
gc.get_referrers()不是线程安全的，可能抛出RuntimeError
为什么 gc.disable() 有时反而让内存更难分析
禁用 GC 看似能“冻结”对象生命周期，方便排查，但实际会让问题更隐蔽。Python 中很多内置类型（如 list、dict）在特定操作中会隐式创建循环引用，依赖 GC 主动清理。
立即学习“Python免费学习笔记（深入）”；
- 禁用后，这些循环引用永久驻留，你看到的“泄漏”其实是本该被回收的正常中间态
-
gc.isenabled()返回False并不意味着 GC 完全停止——某些 C 扩展（如numpy）仍可能触发局部回收 - 真正需要的是可控触发：
gc.collect(2)强制运行 full collection，比禁用更可靠 - 若必须禁用（如性能敏感路径），记得在分析前恢复：
gc.enable()+gc.collect()，否则后续get_objects()结果失真
用 gc.get_objects() 过滤特定类实例的实操要点
当怀疑某类对象堆积时，gc.get_objects() 是起点，但它返回全部活动对象（常超 10 万），直接遍历极慢。
- 不要写
[o for o in gc.get_objects() if isinstance(o, MyClass)]——isinstance在大列表上开销巨大；改用gc.get_objects(generation=0)限定代数，或配合types模块做类型 ID 匹配 - 优先用
gc.get_objects(typ)（Python 3.12+）或gc.get_objects() + type(o) is typ（注意不是isinstance，避免继承干扰） - 结果里包含大量内部对象（如
method、cell），用sys.getsizeof()配合weakref.ref判断是否为“主干实例”更准 - 每次调用都触发一次对象快照，频繁调用本身影响 GC 行为，建议采样间隔 ≥ 1 秒
循环引用的典型模式藏在闭包、回调注册、缓存字典里，而 gc 模块不会告诉你“为什么形成”，只暴露“现在卡在哪”。真正耗时的从来不是开启调试，而是读懂那一长串 referrers 输出里哪一行才是真正的持有者。
