python内存占用过高需定位持续吃内存的源头，用tracemalloc抓分配热点，结合gc状态、objgraph分析引用堆积，关注大对象缓存与rss趋势判断真实泄漏。
Python 内存占用过高，关键不是“看总用量”，而是快速定位谁在持续吃内存、为什么没被释放。多数情况并非代码写错，而是对引用机制和对象生命周期理解偏差导致的隐性堆积。
用 tracemalloc 快速抓出内存增长源头
这是最轻量、最直接的内置方案，适合开发阶段快速验证。
- 启动追踪后执行可疑逻辑，再拍快照对比，能精确到哪一行代码分配了最多内存
- 重点关注
statistics('lineno')排序结果，前几条往往就是问题核心（比如反复 append 到全局列表、未关闭的文件读取缓存） - 若发现某函数调用前后内存明显上涨，可进一步用
compare_to()对比两个快照，只看新增分配
检查循环引用与 GC 状态
引用计数归零才回收，但类实例、嵌套容器相互持有引用时，计数卡在 ≥1，GC 又未及时触发，对象就滞留内存。
- 运行
import gc; gc.get_stats()查看各代回收次数——如果第0代几乎不触发，说明新对象没被清理，可能有泄漏 - 用
objgraph.show_most_common_types(limit=20)看哪些类型数量异常多（如几百个未释放的dict或自定义类实例） - 确认是否存在闭包捕获、信号回调注册、全局事件监听器等长生命周期引用场景
盯住大对象和缓存行为
一个 500MB 的 DataFrame 或缓存字典，比上万个小对象更值得优先处理。
立即学习“Python免费学习笔记（深入）”；
- 用
sys.getsizeof()测基础大小，对嵌套结构配合递归函数或pympler.asizeof获取真实开销 - 检查是否用了
lru_cache却没设maxsize，或手动实现的缓存没做淘汰策略 - 读取大文件时，避免
pd.read_csv()全量加载，改用chunksize迭代，或用dask/polars延迟计算
观察进程级 RSS 而非对象估算值
内存是否真高，最终看操作系统分配给该进程的物理内存（RSS），而不是 Python 自己算出来的“理论大小”。
- 用
psutil.Process().memory_info().rss每隔几秒打印一次，画趋势图——平稳上升即为泄漏，阶梯式跳变则对应大对象创建 - 对比
rss和vms：若 RSS 持续涨而 VMS 不变，大概率是 Python 层引用未释放；若两者同步暴涨，可能是底层 C 扩展（如某些图像库）分配未回收 - 生产环境可用
psutil+ 日志定时采样，无需侵入业务代码
