内存持续升高不等于泄漏，先看RSS趋势是否单调上涨；真泄漏特征是相同请求后内存不回落且gc.get_stats()中第0代collected长期为0或骤降，需用psutil打点2小时以上观察曲线，结合tracemalloc和objgraph定位具体行与引用链。
内存持续升高不等于泄漏，先看 RSS 趋势是否单调上涨
很多 django 项目在容器里跑几小时后 rss（psutil.process().memory_info().rss）稳步上升，但其实只是缓存预占或连接池填充——比如 django.core.cache.backends.locmem.locmemcache、sqlalchemy.pool.queuepool 或模板引擎的内部缓存。真泄漏的特征是：相同请求反复触发后，内存不回落，且 gc.get_stats() 中第 0 代回收数长期为 0 或骤降。
- 用
psutil每 30 秒打点，连续跑 2 小时以上，画 RSS 曲线；平台期或小幅波动属正常，持续斜线上升才需深挖 - 对比压测前后
gc.get_stats()输出，重点关注collected字段是否归零；若第 0 代几乎不回收，说明新对象没被释放，大概率有引用滞留 - 只在特定接口（如报表导出、大文件上传）后内存卡住？优先检查该路径下的临时对象生命周期，别全局扫
Django ORM 是最常见泄漏源，尤其 prefetch_related 和 select_related 用错
prefetch_related 默认用惰性查询+缓存，但若嵌套层级深、关联对象多，会把整棵树加载进内存并长期持有；select_related 虽走 JOIN，但一旦误用于多对多字段，会生成笛卡尔积，瞬间撑爆内存。更隐蔽的是 QuerySet 被赋给模块级变量或闭包捕获，导致整个结果集无法 GC。
- 避免在视图外保存
QuerySet实例，如ALL_USERS = User.objects.all()；改用函数封装，每次调用都新建 QuerySet -
prefetch_related后如果只取部分字段，加.values()或.only()限制载入范围；多对多场景优先用prefetch_related('rel__subrel')而非select_related - 检查自定义 Manager 或 Model 方法里是否有隐式缓存，比如
self._cached_result = ...却没设过期逻辑
全局缓存和信号监听器容易变成“内存黑洞”
Django 的 cache.set() 若没设 timeout，或手动实现的字典缓存没做淘汰，会无限堆积；信号如 post_save 回调若注册在模块顶层且未解绑，每次触发都会新增闭包引用，而闭包又持有了 request、response 等大对象。
- 所有
cache.set()必须显式传timeout，生产环境禁用LocMemCache；用 Redis 缓存时，确认KEY_PREFIX和过期策略已配置 - 信号注册不要写在 models.py 顶层，改用
apps.py的ready()方法，并确保回调函数不捕获 request/response 实例 - 检查中间件里是否有类似
self.request_log = []的实例属性，它会随每个请求累积，且无法被 GC 清理
tracemalloc + objgraph 定位到具体行，别靠猜
在可疑接口里启用 tracemalloc，拍两个快照对比，能直接定位哪行代码分配最多内存；再用 objgraph.show_most_common_types(limit=20) 看哪些类型数量异常——几百个 dict 或自定义 Model 实例，基本就是泄漏点。
- 启动追踪：
tracemalloc.start(); snapshot1 = tracemalloc.take_snapshot()，执行接口后snapshot2 = tracemalloc.take_snapshot() - 查热点：
top_stats = snapshot2.compare_to(snapshot1, 'lineno'); print(top_stats[0])，输出形如myapp/views.py:42: 50.2 MiB - 查引用链：
objgraph.find_backrefers(obj, max_depth=3)，看谁在 hold 这个对象；特别注意weakref以外的强引用
真正难啃的是 C 扩展导致的泄漏——比如某些图像处理库或数据库驱动，它们绕过 Python GC，psutil 显示 RSS 涨但 tracemalloc 无热点，就得换库或加资源限制。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
