Python生产环境内存泄漏主因是代码或库绕过GC，需早期调用tracemalloc.start(25)、主线程采样、信号捕获快照；gc.DEBUG_LEAK仅对特定循环引用有效，禁长期开启；须结合gc.get_count()与/proc/pid/status交叉分析。
Python 服务在生产环境发生内存泄漏，不是 GC 失效了，而是你写的代码或用的库绕过了 GC 的回收条件。它不会报错，但 VmRSS 会持续上涨，直到被 OOM Killer 杀掉。
tracemalloc.start() 必须在进程启动最早期调用
很多团队把 tracemalloc.start() 放在 Web 框架初始化之后、甚至请求处理逻辑里 —— 这等于没开。它只能捕获开启后新分配的内存，早期加载的模块、全局对象、框架启动时创建的单例全都不在视野内。
- 必须在
if __name__ == "__main__":或主模块导入的最顶端执行，早于任何第三方库初始化 - 推荐加参数：
tracemalloc.start(25)，25 是调用栈深度，设太小（如 10）会丢失关键上下文，设太大（如 50）会让内存开销翻倍 - 避免在子线程中调用
take_snapshot()，不同线程快照不兼容；所有快照应在主线程采集 - 不要依赖
atexit自动输出 —— OOM 崩溃时 Python 解释器可能来不及触发注册函数，改用信号捕获：signal.signal(signal.SIGUSR1, lambda s, f: print(...))，手动触发快照
gc.set_debug(gc.DEBUG_LEAK) 只对循环引用有效，别误用成万能开关
gc.DEBUG_LEAK 的本质是打开 GC 调试日志 + 把无法回收的对象塞进 gc.garbage 列表。但它只对“不可达但有 __del__”或“跨代未被扫描到”的循环引用起作用，对全局字典缓存、闭包持有、C 扩展 malloc 的内存完全无感。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 启用后会显著拖慢 GC 速度，**禁止在高并发线上环境长期开启**，仅用于复现阶段的短时诊断
- 如果
gc.collect()返回 0 且gc.garbage为空，不代表没泄漏 —— 更可能是泄漏源根本不在 GC 管理范围内（比如 NumPy 数组底层内存） - 查
gc.garbage里的对象时，别只看类型，用gc.get_referrers(obj)往上翻 2–3 层，重点找dict、list、模块级变量名（如cache、_pool、handlers）
监控不能只看 RSS，要交叉验证 gc.get_count() 和 /proc/[pid]/status
单纯轮询 psutil.Process().memory_info().rss 容易误判：pymalloc 内存池碎片、mmap 分配的大块内存、甚至 GPU 显存（torch）都会计入 RSS，但和 Python 对象无关。真问题往往藏在 GC 代计数和内核态内存映射里。
立即学习“Python免费学习笔记（深入）”；
- 每 30 秒采集一次：
gc.get_count()—— 如果第 0 代长期 ≥ 650，且gc.collect(0)几乎不回收，说明对象生成速度远超 GC 频率，大概率是高频创建短命对象（如日志字符串、临时列表） - 同步读取
/proc/[pid]/status中的VmRSS和VmData：若VmRSS涨但VmData不涨，问题在 Python 堆；若两者齐涨，可能是 C 扩展或 mmap 泄漏 - 用
cat /proc/[pid]/maps | awk '$6 ~ /heap|anon/ {sum += $2} END {print sum}'粗略估算匿名内存增长，排除文件映射干扰
最常被忽略的一点：tracemalloc 的 statistics('lineno') 输出里，同一行可能对应多个分配点 —— 它按源码位置聚合，但实际可能来自不同分支、不同参数组合。定位到行后，必须结合业务逻辑判断是否真泄漏，还是合理缓存。别看到 data = [i for i in range(10000)] 就删，先确认它是不是本该存在的中间结果。
