Python内存泄漏四大源头：全局字典缓存未清理、循环引用+__del__阻塞GC、threading.local残留、闭包捕获大对象；需分别采用LRU限容、弱引用、手动清理、参数解耦等策略防控。
全局字典缓存未清理
Python 中用 dict 做全局缓存是最常见的内存泄漏源头，尤其在 Web 服务或长时运行脚本里。缓存键没做生命周期控制、没设最大容量、没配过期策略，对象就一直挂在内存里不释放。
典型表现是：进程 RSS 内存持续上涨，gc.get_objects() 能查到大量本该被回收的实例；用 objgraph.show_most_common_types() 会看到某个业务类实例数异常高。
- 加限容：用
collections.OrderedDict实现 LRU，或直接上functools.lru_cache(maxsize=128) - 避免用可变类型（如
list、dict）作缓存 key，否则哈希不稳定，导致重复缓存 - 若必须用自定义对象作 key，确保实现了
__hash__和__eq__，且内容不可变
循环引用 + 自定义 __del__
当两个对象互相持有对方引用，又都定义了 __del__ 方法，Python 的循环垃圾回收器（GC）会放弃清理它们——因为无法确定析构顺序，怕调用出错。这些对象就永久滞留在 gc.garbage 里。
常见于事件回调、观察者模式、数据库连接池中：A 持有 B 的回调函数，B 又通过闭包引用 A，再加个 __del__ 收尾逻辑，就锁死了整条引用链。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 优先用弱引用替代强引用：把回调注册改为
weakref.WeakKeyDictionary或weakref.ref(callback) - 彻底避免在关键路径写
__del__；改用上下文管理器（__enter__/__exit__）或显式close()方法 - 定期检查：
import gc; gc.collect(); print(gc.garbage)，一旦非空就要排查
线程局部存储（threading.local）残留
threading.local 看似“线程私有”，但 Python 实际是靠线程 ID 查字典实现的。线程退出后，如果主线程或线程池没主动清理，对应字典项不会自动消失，尤其在使用 concurrent.futures.ThreadPoolExecutor 时容易积累。
现象是：多线程服务跑久了，每个线程的 local 对象（比如 DB 连接、日志 handler）不断增生，sys._current_frames() 查不到，但 gc.get_objects() 能扫出大量未释放实例。
- 不要依赖线程自然退出来清理；在线程任务末尾手动删掉 local 属性：
del threading.local().xxx - 改用更可控的方案：函数参数传入依赖，或用
contextvars.ContextVar（Python 3.7+），它随协程/任务生命周期自动管理 - 若必须用
threading.local，可在 executor 的initializer和finalizer中统一管理初始化与清空
闭包捕获大对象未释放
闭包函数会隐式持有外层作用域的所有变量，哪怕只用其中一个小字段。如果外层有个大 list、pandas.DataFrame 或文件句柄，而闭包只用来取一个配置值，整个大对象仍无法被回收。
这种泄漏隐蔽性强，objgraph.find_backref_chain() 往往指向一个匿名函数，溯源困难。
- 显式解耦：把需要的值提前取出，传给闭包作为参数，而不是让它捕获整个作用域
- 用
functools.partial替代闭包，它只绑定指定参数，不捕获自由变量 - 调试时打印
func.__code__.co_freevars和func.__closure__，确认闭包实际绑定了哪些对象
真正难处理的不是单点泄漏，而是多个小泄漏叠加后触发 GC 阈值升高、延迟回收，让问题变得间歇且难以复现。建议在关键服务启动时设置 gc.set_debug(gc.DEBUG_UNCOLLECTABLE)，并配合 tracemalloc 定期快照比对。
