不能——tracemalloc仅提供快照式内存分配追踪，需手动控制请求前后采样、过滤噪音、比对差异，并结合调用链与缓存逻辑分析根源，无法自动关联Web请求生命周期。
tracemalloc 能不能直接定位 Web 应用的内存泄漏？
不能——tracemalloc 本身不监控、不告警、不自动关联请求生命周期，它只是快照式内存分配追踪器。你得自己决定「什么时候拍快照」「比哪两帧」「怎么过滤噪音」。Web 应用（比如 Flask/FastAPI）里对象生命周期混杂、异步任务穿插、全局缓存常驻，直接开 tracemalloc.start() 然后等 OOM 再 dump，大概率只看到 dict 和 list 占满 top，但不知道谁 new 的、在哪没释放。
如何用 tracemalloc 捕获一次真实请求引发的泄漏？
关键不是“全程开启”，而是「请求前后精准对比」。以 Flask 为例，在中间件中做轻量级采样：
- 只在特定路由（如带
?debug=mem参数）或低流量时段触发，避免性能抖动 - 用
tracemalloc.take_snapshot()在请求进入前拍一次，响应发出后再拍一次 - 两次快照用
snapshot.filter_traces()过滤掉标准库和框架底层路径，聚焦你的业务模块，例如：filter_traces([tracemalloc.Filter(True, "*myapp/*")]) - 用
top_stats('lineno', cumulative=True)查新增分配行，重点关注new_bytes差值大的条目，不是总大小
示例片段：
import tracemalloc <h1>请求开始前</h1><p>tracemalloc.start() snapshot1 = tracemalloc.take_snapshot()</p><h1>... 处理请求 ...</h1><p>snapshot2 = tracemalloc.take_snapshot() stats = snapshot2.compare_to(snapshot1, 'lineno') for stat in stats[:5]: print(stat)
为什么有时看到大量 bytearray 或 __new__ 却找不到源头？
因为 tracemalloc 记录的是「分配点」，不是「持有者」。比如一个 requests.Response.content 被缓存进全局字典，分配发生在 response.py 里，但泄漏根因是你在 cache.py 里忘了设 TTL 或 key 冲突导致无限堆积。这时候要结合：
立即学习“Python免费学习笔记（深入）”；
-
tracemalloc.get_traceback_limit()设大一点（默认 1），否则只显示最上层调用 - 用
stat.traceback.format()[0]看完整调用链，重点找你代码里的函数名，别被urllib3或json.loads带偏 - 检查是否用了
lru_cache、functools.cache或手动 dict 缓存，且 key 不稳定（如含时间戳、UUID） - 异步场景下，
asyncio.create_task()启动的任务若没 await 或没加 cancel 逻辑，其局部变量可能长期挂起
tracemalloc 和 psutil 内存读数为啥差很多？
psutil.Process().memory_info().rss 是进程物理内存占用，含 Python 解释器开销、未归还给系统的 malloc 块、共享库等；tracemalloc 只统计 Python 对象堆内分配（通过 malloc 分配但经 Python 内存管理器中转的部分）。两者数值天然不等，别拿 RSS 下降就断定泄漏修复了——可能只是 GC 暂时回收，而对象引用链还在。更可靠的做法是：固定请求压测 100 次，看 tracemalloc 中同一行 new_bytes 是否线性增长，这才是泄漏铁证。
真正难的不是启动 tracemalloc，是把「一次请求」从 Web 生命周期里干净地切出来，同时避开日志、中间件、ORM session 等自带缓存的干扰项。漏掉一个 session.remove() 或多写一个 global cache = {}，都可能让快照结果完全失真。
