Python循环引用导致内存泄漏，因引用计数无法归零且含__del__方法时GC放弃清理；weakref可破环但需谨慎使用，定位需借助gc模块分析garbage与referrers。
循环引用在 Python 中为什么会导致内存泄漏
Python 主要靠引用计数回收对象，但当两个或多个对象互相持有对方的引用（比如 A.ref = B 且 B.ref = A），它们的引用计数永远不会降到 0，即使外部已无任何变量指向它们。此时 CPython 的循环垃圾收集器（GC）本该介入，但前提是这些对象**没有实现 __del__ 方法**——一旦有，GC 就会放弃清理，因为析构顺序无法安全确定。
- 常见于自定义类中手动维护双向关系：树节点父子互指、观察者模式中 subject 和 observer 互相保存引用
-
weakref是最直接的解法，但不是所有场景都适用（比如需要强引用语义时） - 显式调用
gc.collect()可临时验证是否存在待回收的循环，但不能作为常规手段——它开销大、不可预测，且不解决根本问题
如何快速定位疑似循环引用的对象
别等 OOM 才查。用 gc.get_objects() 配合 gc.get_referrers() 可以逆向追踪谁在持有一个对象的引用，再层层剥开。
- 先禁用 GC：
gc.disable()，避免干扰；然后触发可疑操作（如创建一批对象、执行一次回调） - 用
gc.collect(0)强制运行第 0 代收集，再检查len(gc.garbage)—— 若非零，说明有未处理的循环引用被 GC 放进了garbage列表 - 对
gc.garbage中的每个对象，调用gc.get_referrers(obj)查看谁引用了它；反复下钻，直到找到源头（通常是某个全局容器或长生命周期对象） - 注意：
gc.get_referrers()返回结果可能包含帧对象（frame），它们本身也参与循环，需过滤掉types.FrameType
weakref 的正确用法和典型误用
weakref 不是万能胶布，用错反而让逻辑出 bug 或掩盖问题。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 用
weakref.ref(obj)替代直接赋值，访问前必须先调用返回的弱引用对象（如ref()），它可能返回None—— 忘记判空是常见 crash 点 - 对容器类（如
list、dict）存弱引用时，别直接存weakref.ref(obj)，而要用weakref.WeakKeyDictionary或weakref.WeakValueDictionary，它们自动处理 key/value 失效逻辑 - 不要对不可变对象（如
int、str、tuple）用weakref—— 它们可能被驻留（interned），生命周期不由引用计数控制，弱引用行为不可靠 - 类方法绑定（bound method）默认强引用实例，若需弱引用，得用
weakref.WeakMethod（Python 3.4+）或手动拆解为weakref.ref(inst)+ 函数对象
哪些情况 GC 根本不会尝试回收
不是所有循环都能进 garbage，有些会被 GC 主动跳过，导致“看不见的泄漏”。
立即学习“Python免费学习笔记（深入）”；
- 对象属于“原子类型”且没自定义
__del__：比如纯dict、list构成的循环，GC 能处理，但速度慢、延迟高，尤其在大量小对象时 - 对象在
__del__中又触发新引用（例如日志写入、发通知），可能引发 GC 拒绝清理并静默丢弃该对象 - 线程局部存储（
threading.local）中的对象，若其值构成循环，GC 在非主线程中可能不扫描该线程的栈帧，导致漏收 - C 扩展模块分配的对象（如 NumPy 数组、Cython 类实例）若未正确实现 tp_traverse / tp_clear，GC 完全感知不到它们是否参与循环
真正难缠的从来不是“能不能检测”，而是“检测到了却不敢动”——比如生产环境里一个带 __del__ 的老模块，改它得通读十年前的 C API 文档。
