flask开发模式下内存只涨不降主因是debug=true触发模板自动重载，导致ast缓存和源码引用无法被gc回收；应禁用debug、关闭auto_reload、避免全局大对象，并用tracemalloc和objgraph定位泄漏源。
为什么 flask run 启动后内存只涨不降
Flask 默认用 Werkzeug 开发服务器，单进程多线程模式下，全局变量、闭包引用、未清理的缓存或日志对象都可能长期驻留。更关键的是：**开发模式下模板自动重载 + debug=True 会保留大量 AST 缓存和源码引用，导致对象无法被 GC 回收**。
常见现象：ps aux | grep python 看到 RSS 持续上涨；用 tracemalloc 发现 werkzeug.routing.Rule 或 jinja2.Template 实例数异常增长；重启服务后内存回落，但再次请求又爬升。
- 禁用调试模式：
debug=False（哪怕只是临时测试） - 关闭模板自动重载：
app.jinja_env.auto_reload = False - 避免在模块顶层或
app对象上挂载大对象（比如读入整个 JSON 文件赋值给app.config['DATA']）
用 tracemalloc 定位谁在偷偷 hold 住内存
tracemalloc 是 Python 标准库中最轻量、最准的内存分配追踪工具，不需要安装第三方包，也不干扰 Flask 生命周期。重点不是“总内存多少”，而是“哪些调用路径持续分配新对象且没释放”。
实操建议：
- 在应用启动前就开启：
import tracemalloc; tracemalloc.start() - 在可疑路由里拍快照：
snapshot1 = tracemalloc.take_snapshot()，等几轮请求后再拍snapshot2，用snapshot2.compare_to(snapshot1, 'lineno')查差异 - 过滤掉标准库路径，聚焦你自己的模块：
filter = tracemalloc.Filter(inclusive=True, filename_pattern="*/myapp/*") - 注意：
tracemalloc本身有开销，别长期开着，定位完就关（tracemalloc.stop()）
objgraph 显示谁在阻止 GC —— 尤其适合查循环引用
Flask 中很多泄露不是因为分配得多，而是因为对象被意外强引用（比如函数闭包捕获了 request context，或信号回调里存了 response 对象）。objgraph 能可视化引用链，比看 gc.get_referrers() 直观得多。
典型场景：
- 自定义
@app.before_request里把request存进全局 dict - 用
functools.lru_cache缓存了带flask.g或request的函数结果 - 日志 handler 持有 request 上下文对象（尤其用了结构化日志如
structlog）
快速验证步骤：
pip install objgraph- 在泄露明显时执行：
objgraph.show_growth(limit=10)看哪些类型实例数突增 - 挑一个可疑实例：
objgraph.show_backrefs([obj], max_depth=5, too_many=10)，找它被谁持有着
Gunicorn + --max-requests 是兜底手段，不是根治方案
很多人一见内存涨就加 --max-requests 1000 让 worker 自动重启。这确实能缓解 OOM，但掩盖了真正的问题：泄漏对象会在每次 fork 后继续累积，甚至污染新 worker（尤其用 preload=True 时）。
真正该做的：
- 确认泄漏是否复现在单 worker 单线程模式：
gunicorn --workers=1 --threads=1 --preload myapp:app - 如果仍泄漏，说明是代码层问题，不是并发模型导致的
-
--max-requests只应作为上线前的临时缓冲，数值设太小会导致频繁 reload 影响可用性；设太大又起不到作用 - 配合
--max-requests-jitter避免所有 worker 同时重启
最常被忽略的一点：Flask 应用里混用异步逻辑（比如 async def 路由 + 同步数据库驱动），会让 event loop 和 request context 的生命周期错乱，造成对象滞留——这种泄漏 tracemalloc 很难直接抓到，得靠 objgraph 追引用链才能看清。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
