memory_profiler仅统计每行新分配内存，不追踪对象生命周期或引用链，适合定位单次执行的内存尖峰，而非长周期泄漏；真正卡住内存的是强引用未释放，需用gc.get_referrers()或objgraph分析。
内存持续升高不释放，大概率不是“没回收”，而是对象还在被强引用着——memory_profiler能帮你看到哪行代码在吃内存，但不能告诉你谁在死死拽着它不放。
为什么memory_profiler常被误用
很多人装上就加@profile，跑完看输出里某行“+10MB”，就去改那行。结果重跑，RSS 还是涨。问题在于：memory_profiler只统计每行新分配的内存，不追踪对象生命周期，也不显示引用链。
- 它对生成器、惰性计算（如
map()、filter()）几乎不报内存——实际可能缓存了大量中间结果 - 它无法区分“临时变量刚分配”和“全局缓存持续累积”，比如
cache.append(obj)在循环里执行 1000 次，memory_profiler会标出 1000 行“+很小”，但根本看不出cache本身已膨胀到 500MB - 对 NumPy/Pandas 视图（view）完全失明：一个
df.iloc[:1000]可能只占几 KB 引用开销，但底层 buffer 仍是整个 GB 级 DataFrame ——memory_profiler不会警告你
memory_profiler该什么时候用、怎么用才有效
它适合定位“单次执行中明显异常的内存尖峰”，比如函数内加载大文件、拼接超长字符串、误用list(range(10**7))。前提是：你已经排除了长周期引用（全局变量、闭包、信号监听器）干扰。
- 启动时加
-M参数启用多行监控：python -m memory_profiler -M your_script.py - 关注
Mem usage列的**跳变点**，而非累计值；例如从 80MB → 280MB 那一行，比后面缓慢爬升的几十行更有价值 - 配合
stream=True写入日志，避免终端刷屏丢失关键帧：@profile(stream=open('mem.log', 'w')) - 对可疑函数，用
mprof run+mprof plot画趋势图，确认是单次暴涨还是随时间线性增长——后者基本可排除memory_profiler主责，该切tracemalloc或psutil
它报不出问题的三类典型场景
如果你发现memory_profiler输出平平无奇，但psutil.Process().memory_info().rss每分钟涨 50MB，大概率掉进以下坑里：
立即学习“Python免费学习笔记（深入）”；
-
global_cache = {}在模块顶层，被某个 handler 不断cache[key] = big_result，而 key 永远不重复——memory_profiler只记下每次赋值的开销，不提醒你字典本身已存了 2 万个键 - 使用了
lru_cache(maxsize=None)装饰器处理高频率小参数函数，缓存无限增长；它分配内存的动作分散在每次调用里，memory_profiler无法聚合识别 - 第三方库（如
requests.adapters.HTTPAdapter）内部维护连接池或缓冲区，Python 层看不到对象，memory_profiler自然不统计——这时得看/proc/[pid]/maps或用gdb --pid查 native 堆
真正卡住内存的，往往不是某行代码“分配得多”，而是某处引用“松不开手”。memory_profiler是听诊器，不是 CT 机；想看清谁在拽着对象不放，得切到gc.get_referrers()或objgraph。别让它替你做本不属于它的判断。
