弱引用不能自动避免内存泄漏，其生效前提是目标对象除弱引用外无其他强引用；典型用途包括weakvaluedictionary缓存、观察者模式解耦等，但需注意key生命周期、线程安全及finalize的不确定性。
弱引用不是用来“避免内存泄漏”的万能解药
很多人一看到 weakref 就默认它能自动清理循环引用，结果发现对象还是没被回收——因为弱引用本身不改变引用计数，只是提供一个“可被回收时还能访问”的通道。它真正起作用的前提是：目标对象**除了弱引用之外，没有其他强引用存在**。
常见错误现象：weakref.ref(obj)() 返回 None 却不知道为什么；或者以为加了 weakref 就能放心存对象进全局缓存，结果缓存越积越多。
- 使用场景典型但有限：缓存（配合
weakref.WeakValueDictionary）、观察者模式中避免监听器拖住被观察对象、框架内部管理临时绑定（如 Tkinter 或某些 GUI 事件回调） -
weakref.ref返回的是一个 callable，必须加()才能取值；而weakref.proxy直接像原对象一样用，但一旦原对象销毁，立刻抛出ReferenceError - 性能影响极小，但要注意：每次调用
ref()都有轻微开销；频繁创建/销毁弱引用本身不会触发 GC，但可能让 GC 多扫几个条目
WeakValueDictionary 是最安全的缓存方案之一
它内部用弱引用来持有 value，key 还是强引用。这意味着：只要某个 value 对象在别处没了强引用，它就会自动从字典里消失——不用手动清理，也不用定时扫描。
但容易踩的坑是误以为 key 也被弱化了。比如你用一个临时字符串做 key，缓存很快失效，不是因为 value 被回收，而是 key 字符串被 GC（虽然字符串通常常驻，但若 key 是自定义对象且没重写 __hash__ 和 __eq__，就可能出问题）。
立即学习“Python免费学习笔记（深入）”；
- 只适合 value 易于重建、且重建成本可控的场景（比如解析后的配置对象、渲染中间结果）
- key 必须是可哈希的，且生命周期应比 value 更长；否则 key 先没了，整个键值对就“逻辑上丢失”了
- 不要在多线程里直接遍历
WeakValueDictionary，因为遍历时 value 可能随时被回收，导致RuntimeError: dictionary changed size during iteration
weakref.finalize 不等于析构函数
weakref.finalize 注册的是一个“当对象即将被销毁时执行的回调”，但它不保证一定执行，也不保证执行时机——GC 可能延迟、也可能根本没运行（比如程序结束前没触发 full GC），甚至 CPython 的子解释器或某些嵌入场景下完全不触发。
常见错误：用它来释放文件句柄、关闭 socket、写日志——这些操作必须显式做，不能依赖 finalize。
- 适合做低成本、非关键的清理提示，比如打印一句
"Object {id} cleaned up"用于调试 - 回调函数不能捕获外部局部变量（除非用闭包或默认参数固化），否则可能意外延长对象生命周期
- 同一个对象可以注册多个 finalize，但它们执行顺序不确定；如果回调里又创建了对该对象的新强引用，该 finalize 就不会再触发
自定义类要支持弱引用，得先确认 __slots__ 和 __weakref__
默认情况下类实例支持弱引用，但如果你用了 __slots__ 却没显式留出 __weakref__，就会报 TypeError: cannot create weak reference to 'MyClass' object。
这不是 bug，是设计：Python 把 __weakref__ 当作一个特殊 slot，必须主动声明才能启用弱引用能力。
- 正确写法：
__slots__ = ['a', 'b', '__weakref__']；漏掉__weakref__就彻底禁用弱引用 - 如果类继承自内置类型（如
list、dict），即使没__slots__，也不能被弱引用（因为它们不支持） - 使用
weakref.proxy时尤其要注意：代理对象不可序列化，也不能传给某些 C 扩展（比如 numpy 数组构造函数会拒绝 proxy）
弱引用真正的复杂点不在语法，而在对“谁还持有着这个对象”的准确判断。很多时候你以为只有弱引用了，其实 logging 模块的 handler、threading.local、甚至某个闭包里的变量还在悄悄抓着它。查不清强引用链，weakref 就只是个摆设。
