flask内存只涨不降的主因是debug=true启用werkzeug模板ast缓存与源码重载机制，导致对象被强引用无法gc；应设debug=false、禁用jinja2.auto_reload，并用tracemalloc定位分配热点、objgraph分析引用链、gc日志诊断回收失败。
Flask内存只涨不降，先关debug=True和auto_reload
开发模式下内存爬升最快的原因不是你代码写错了，而是debug=True触发了 Werkzeug 的模板 AST 缓存 + 源码重载机制，这些对象被强引用住，GC 根本碰不到。哪怕只是本地测试，也建议立刻设为 debug=False；如果非要热重载，手动关掉 Jinja2 自动重载：app.jinja_env.auto_reload = False。
- 别信“我就跑一会儿”，只要请求进来过，
werkzeug.routing.Rule和jinja2.Template实例就会累积 - 重启服务后内存回落？说明泄漏源是运行时动态生成的对象，不是启动时加载的模块级大对象
- 检查是否误把
flask run --debug当成“只是开个调试器”，其实它等价于app.run(debug=True)，整套重载链全开
用tracemalloc定位谁在持续分配新对象
tracemalloc 是标准库中最准的轻量工具，不干扰生命周期，专抓“新增但没释放”的路径。重点不是总内存多少，而是哪些调用行反复 new 对象却没人 hold 住释放时机。
- 启动前就加：
import tracemalloc; tracemalloc.start(10)（10 层栈深度够用） - 在可疑路由里拍两个快照：
snapshot1 = tracemalloc.take_snapshot()→ 几轮请求 →snapshot2 = tracemalloc.take_snapshot() - 比对差异：
snapshot2.compare_to(snapshot1, 'lineno')，过滤掉*/venv/*和*/site-packages/*，只看自己模块路径 - 别长期开着——定位完立刻
tracemalloc.stop()，否则自身开销会干扰判断
查循环引用和强引用残留，用objgraph看谁卡在 GC 外面
很多泄漏不是分配得多，而是某个闭包、信号回调或线程局部变量悄悄 hold 住了 request context 或 response 对象，导致整条引用链无法回收。这时候 gc.get_objects() 只能看到数量，objgraph 才能画出谁在挡路。
- 装它：
pip install objgraph（需系统有 Graphviz 才能出图） - 快速筛查：
objgraph.show_most_common_types(limit=10)看是不是dict、list或你自己的类暴增 - 追踪增长：
objgraph.show_growth(limit=5)，执行前后各跑一次，直接看到新增了哪些类实例 - 揪具体对象：
objgraph.show_backrefs([leaked_obj], max_depth=3)，图里箭头方向就是“谁引用了谁”，一眼识别闭包捕获、全局缓存、未注销回调
别忽略gc模块的原始日志和代际统计
当 objgraph 显示某类对象数量稳定但内存不降，大概率是进了第 2 代（最老代）还没被回收——这时得看 GC 自己说了什么。启用调试日志，比任何第三方工具都接近底层事实。
- 加这段代码到启动逻辑：
import gc; gc.set_debug(gc.DEBUG_UNCOLLECTABLE | gc.DEBUG_STATS) - 手动触发回收：
gc.collect()，观察输出里有没有uncollectable行，以及类型如function、dict是否反复出现 - 定期采样：
gc.get_count()返回三元组，如果第 2 个数（第 1 代）或第 3 个数（第 2 代）持续变大，说明 GC 跟不上节奏 - 注意：
gc.garbage非空时，说明存在带__del__的循环引用，这种必须改代码，weakref 或删__del__是唯二解法
tracemalloc 告诉你“哪里在长”，objgraph 告诉你“谁在拦着不走”，gc 日志告诉你“为什么 GC 放弃治疗”。三者顺序不能乱：先停 debug，再抓分配热点，最后查引用锁死点。漏掉任意一环，都可能把泄漏误判成“正常内存占用”。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
