先观察RSS内存是否持续上涨、GC无法回收、重启回落且与请求量正相关；再用ps aux监控RES列，压测10–30分钟验证增长趋势；排除__del__未定义、循环引用、全局缓存、DB连接未关闭等常见原因；最后用memory_profiler或tracemalloc定位泄漏函数。
怎么确认Flask应用真有内存泄漏
别急着加监控工具，先看现象是否符合内存泄漏特征：进程 RSS 内存持续上涨、GC 无法回收、重启后回落、且与请求量正相关。用 ps aux --sort=-%mem | head -5 观察 flask run 或 gunicorn worker 进程的 RES 列，连续压测 10–30 分钟，每分钟记录一次；如果稳定增长（比如每千次请求涨 2–5MB），再深入排查。
注意排除干扰项：__del__ 未定义、循环引用、全局缓存未清理、数据库连接未 close、日志 handler 持有 request 上下文——这些比框架本身更容易导致泄漏。
用 memory_profiler 定位具体函数
memory_profiler 不适合线上，但对本地复现场景极有效。它能按行显示内存增量，精准锁定泄漏源头。
- 安装：
pip install memory-profiler - 在疑似泄漏的视图函数或蓝本模块顶部加装饰器：
@profile（注意不是@memory_profiler.profile，后者是旧写法） - 用命令运行：
python -m memory_profiler app.py，或配合mprof记录曲线：mprof run --include-children python app.py→mprof plot - 关键看
Mem usage列中「差值」持续为正的行，尤其是反复调用却未释放的对象创建处（如json.loads()后没 del、pandas.read_csv()返回 DataFrame 未清空）
常见陷阱：@profile 只对同步函数生效；若用 async def 或 Celery 任务，需改用 tracemalloc 配合 snapshot.compare_to()。
立即学习“Python免费学习笔记（深入）”；
给 Flask 加轻量中间件做请求级内存快照
不依赖外部 APM，自己写一个中间件，在每次请求前后抓取内存基线，输出异常涨幅（>5MB）的 endpoint 和峰值内存。
from flask import g, request
import tracemalloc
<p>def init_memory_middleware(app):
tracemalloc.start(10) # 保存 10 层调用栈</p><pre class='brush:python;toolbar:false;'>@app.before_request
def before_req():
g.mem_before = tracemalloc.take_snapshot()
@app.after_request
def after_req(response):
if hasattr(g, 'mem_before'):
mem_after = tracemalloc.take_snapshot()
top_stats = mem_after.compare_to(g.mem_before, 'lineno')
leak_bytes = sum(stat.size_diff for stat in top_stats[:3])
if leak_bytes > 5 * 1024 * 1024: # 超 5MB 打日志
app.logger.warning(
f"High mem delta on {request.endpoint}: {leak_bytes/1024/1024:.1f}MB"
)
return response这段代码必须放在 app.run() 之前调用 init_memory_middleware(app)；tracemalloc.start() 不能放在 before_request 里，否则开销过大；采样深度设为 10 是平衡精度和性能的常用值。
为什么 gunicorn + Flask 更容易漏内存
gunicorn 的 worker 复用机制会让泄漏对象跨请求存活，而开发服务器（flask run）每次请求都重建上下文，掩盖问题。
- 检查
gunicorn --max-requests和--max-requests-jitter：设为 1000–3000 可强制回收 worker，缓解泄漏影响（但只是掩耳盗铃） - 禁用
preload=True：避免模块级变量（如全局 dict、单例 DB session）被所有 worker 共享并累积 - 确认
worker-class：用sync而非gevent或eventlet，后两者因协程上下文管理更复杂，易引发隐式引用
真正要解决，得顺着中间件打的日志，找到那个 /api/report 接口里反复 new 的 PdfFileReader 实例，或者忘了 session.remove() 的 SQLAlchemy session。
