@profile在长连接服务中无效，需手动注入LineProfiler、按事件打点记录内存增量、用gc.get_objects()和objgraph验证泄漏源，并禁用debug=True等隐形泄漏源。
长连接服务里@profile根本不起作用
直接给 handler 加 @profile，运行后没任何输出——这不是你漏装插件，而是启动方式错了。python -m memory_profiler 只对脚本直执行生效，而 Flask 长连接服务（比如用 uvicorn、gunicorn 或 app.run()）压根不走这个入口。装饰器被加载了，但 profiler 没被激活。
必须把监控“注入”到服务生命周期里：
- 用
memory_profiler.LineProfiler手动包装关键函数，比如handle_message()，在请求入口处调用lp.enable()/lp.disable() - 别写在模块顶层；改用运行时 patch，例如在
app.on_startup（FastAPI）或before_first_request（Flask）里注册 - 多进程部署（
gunicorn --workers 4）下，默认不追踪子进程；得加--include-children参数，并确保每个 worker 都 import 了 profiler
固定间隔采样会错过真实泄漏点
mprof run --interval=0.1 看起来很细，但对长连接是假精细：连接空闲时内存平稳，真正增长只发生在某次请求处理的几十毫秒内，固定采样大概率拍在“平缓期”，看到的是爬升曲线，不是泄漏源。
真正有效的做法是按事件打点：
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 在请求开始前记录
psutil.Process().memory_info().rss，结束后再记一次，差值才是该请求真实内存增量 - 对高频心跳请求加计数器，每 100 次或每 5 秒 flush 一次 delta 到日志文件
- 禁用
mprof自动采样，改用mprof record+ 自定义信号（如kill -USR1 $PID）手动触发快照，精准抓取疑似时刻
Increment为正 ≠ 内存泄漏，尤其在长连接中
看到某行 Increment 持续 +2MB，别急着删代码。Python 内存池机制会让小对象反复分配/释放时复用底层内存块，rss 不降，但 Python 对象早已被 GC 回收；memory_profiler 显示的是 C 层 malloc 变化，不是对象生命周期。
更可靠的交叉验证方式：
- 用
gc.get_objects()定期检查可疑类实例数量，例如：[o for o in gc.get_objects() if isinstance(o, MyWebSocketConnection)]，看是否只增不减 - 配合
objgraph.show_growth(limit=5)，比对两次快照间新增的类实例，确认是对象堆积还是内存池假象 - 若发现
dict、list暴增但没对应业务逻辑，大概率是闭包捕获了request或全局缓存未清理
debug=True 和 auto_reload 是开发模式下的隐形泄漏源
本地调试时内存越跑越高？大概率不是你写的业务逻辑有问题，而是 debug=True 开启了 Werkzeug 的模板 AST 缓存 + 源码重载机制，这些对象被强引用住，GC 根本碰不到。
实操建议：
- 立刻设
debug=False；非要热重载，关掉 Jinja2：app.jinja_env.auto_reload = False - 检查是否误把
flask run --debug当成“只是开个调试器”，其实它等价于app.run(debug=True)，整套重载链全开 - 重启后内存回落？说明泄漏源是运行时动态生成的对象，不是模块级大对象——优先查
EVENT_CACHE = []这类全局容器和异常处理器里的上下文引用
长连接场景下最危险的不是分配得多，而是某个闭包、信号回调或线程局部变量悄悄 hold 住了 request context，这种引用链靠 gc.get_objects() 看不到，必须用 objgraph.show_backrefs() 才能揪出来。
