最直接跨平台查Python进程内存占用的方法是psutil.Process().memory_info().rss，它返回实际物理内存字节数；tracemalloc可定位泄漏源头，需程序开头启动并设足够跟踪容量；gc.collect()对RSS几乎无影响，不能用于释放内存。
用 psutil 实时查 Python 进程内存占用
最直接、跨平台、不侵入业务代码的方法就是靠 psutil 查当前进程的 memory_info().rss。它返回的是实际物理内存占用（字节），比 sys.getsizeof() 可靠得多——后者只算对象本身，不算引用的子对象或 C 扩展分配的内存。
常见错误是调用 psutil.Process().memory_info().vms（虚拟内存），它在 Linux 上可能虚高几十 GB，完全不能反映真实压力；rss（Resident Set Size）才是你该盯的数字。
- 安装：
pip install psutil - 获取当前进程 RSS：
import psutil; psutil.Process().memory_info().rss - 每秒打印一次（调试用）：
while True: print(psutil.Process().memory_info().rss / 1024 / 1024); time.sleep(1) - 注意：Windows 下需管理员权限才能读取其他进程，但查自己进程始终可行
tracemalloc 定位内存泄漏源头
当你发现 RSS 持续上涨，psutil 只能告诉你“涨了”，而 tracemalloc（Python 3.4+ 内置）能告诉你“从哪涨的”。它记录每次 malloc 调用的文件和行号，适合定位缓存没清、闭包持有了大对象、全局列表不断 append 这类问题。
容易踩的坑是启动太晚——必须在程序最开头就 tracemalloc.start()，否则漏掉模块导入阶段的分配；另外默认只跟踪前 256KB 分配，大对象可能被截断，建议设大点：tracemalloc.start(1024 * 1024)（1MB）。
立即学习“Python免费学习笔记（深入）”；
- 启动后拍快照：
snapshot1 = tracemalloc.take_snapshot() - 运行可疑逻辑，再拍一次：
snapshot2 = tracemalloc.take_snapshot() - 对比差异：
top_stats = snapshot2.compare_to(snapshot1, 'lineno') - 看前 10 行：
for stat in top_stats[:10]: print(stat)
避免 gc.collect() 误判内存是否“可回收”
很多人看到内存不降，第一反应是手动 gc.collect()，然后发现 RSS 没变，就以为“内存泄漏了”。其实不是——CPython 的垃圾回收只管循环引用，而 RSS 不降往往是因为：内存被 mmap 分配（如 NumPy 数组）、C 扩展（如 OpenCV）自己管理内存、或者操作系统没立刻把页还给系统（尤其 Linux 的 malloc 会缓存空闲页供后续复用）。
这时候 gc.collect() 返回值是回收的对象数，但它对 RSS 几乎没影响。别把它当内存释放开关用。
-
gc.collect()主要用于打破循环引用，比如自引用类实例、闭包互相持有 - 想强制归还内存？基本做不到。Linux 下可试
malloc_trim(0)（需 ctypes 调用，且不一定生效） - 更靠谱的做法：用
tracemalloc看对象分配路径，而不是盯着gc数字
生产环境慎用 pympler 和 objgraph
pympler 的 asizeof 和 objgraph 的 show_most_common_types 在调试阶段很有用，但它们会遍历整个对象图，触发大量属性访问和 __dict__ 读取，在生产服务里跑一次可能卡住几秒，甚至引发超时。它们也不适合高频监控——开销太大，且结果不稳定（比如某些对象动态生成属性，每次统计结果不同）。
真正上线后，只保留 psutil + 定期 tracemalloc 快照（按需开启），其余全砍掉。复杂度藏在对象生命周期里，不在工具多寡上。
