tracemalloc可快速定位python内存增长源头：需尽早调用start()，在稳定复现路径前后take_snapshot()，再compare_to()查增量代码行；注意其不跟踪c扩展内存。
用 tracemalloc 快速锁定内存增长源头
别等服务 OOM 才动手，tracemalloc 是标准库里最轻量、最准的“内存探针”，它能直接告诉你哪行代码在疯狂分配对象。关键不是开了就完事，而是时机和比对方式：
-
tracemalloc.start()必须放在程序启动最早期（比如__main__.py第一行），否则漏掉初始化阶段的泄漏源 - 复现泄漏路径前拍一次快照
snapshot1 = tracemalloc.take_snapshot()，跑完可疑操作后再拍一次snapshot2 - 用
snapshot1.compare_to(snapshot2, 'lineno')查增量最大的 10 行——重点看list.append、dict.__setitem__、json.loads这类高频分配点 - 生产环境加参数控制开销：
tracemalloc.start(256)限制帧数，tracemalloc.set_traceback_limit(10)防止栈爆炸
注意：tracemalloc 不跟踪 C 扩展（如 NumPy 底层内存），如果怀疑是这类泄漏，得换 memray 或 valgrind。
用 gc.get_referrers() 找出谁“抓着不放”
循环引用本身 Python 能回收，真正卡住 GC 的，是那些“意外持有者”。gc.get_referrers(obj) 比 gc.get_referents() 有用得多——它回答的是“谁在引用我”，而不是“我在引用谁”：
- 先手动触发
gc.collect()，再用[o for o in gc.get_objects() if isinstance(o, YourClass)]看残留实例数是否异常 - 挑一个残留实例
obj，调gc.get_referrers(obj)，重点关注返回结果里的：dict（尤其是模块级全局字典）、list（缓存池）、module（模块变量）、function（装饰器闭包）、frame（未结束的协程帧） - 如果返回里有
functools._lru_cache_wrapper，检查对应函数是否用了@lru_cache且没设maxsize，或缓存了带状态的对象 - 如果出现
threading.local()实例，确认多线程环境下是否忘了调local_obj.__dict__.clear()
警惕 __del__ 和弱引用混用导致 GC 放弃
只要循环里任意一个对象定义了 __del__ 方法，整个环就进 gc.garbage 且永不回收。更隐蔽的是：你可能没写 __del__，但用了 weakref.ref(obj, callback) —— 回调函数闭包会隐式持有所在作用域里的对象，形成新强引用链：
- 临时注释掉所有
def __del__(self):，再测内存是否回落，这是最快验证方式 - 避免在
__del__里访问日志器、全局配置、数据库连接等可能已被销毁的对象，否则异常会中断 GC 流程 - 用
weakref.finalize(obj, func)替代手动weakref.ref+ 回调，它不依赖闭包，更安全 - 检查第三方库（如
requests.adapters.HTTPAdapter）是否内部用了弱引用回调，升级到新版常已修复
检查异步任务和信号监听器是否“幽灵驻留”
asyncio 里的泄漏最难发现：协程对象本身小，但它绑定的帧对象（frame）和局部变量会一直挂着，尤其当 create_task 后忘了 await 或没 cancel：
- 用
asyncio.all_tasks()列出所有存活 task，过滤出done() == False and cancelled() == False的——这些就是“幽灵 task” - 注册事件监听器（如 PyQt 信号、Flask
teardown_appcontext）后，务必反注册；否则监听器闭包会持有所属对象，导致整条链无法释放 - 日志打点时慎用
logging.info(f"got {big_obj}")，字符串格式化会把big_obj的整个引用链拖进帧对象 - AI 智能体场景中，对话历史、工具缓存、向量检索器必须显式截断或置空，不能只靠 GC
真正的难点不在工具怎么用，而在判断“这个引用到底该不该存在”——很多时候泄漏不是代码写错了，而是业务逻辑里那条本该断开的引用链，被开发者下意识地当成“理所当然”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
