Python内存管理核心是引用计数、gc模块、sys.getrefcount和循环引用检测；调试需关注临时引用干扰、用gc.get_referrers查持有者、weakref防泄漏但不减分配开销，边界问题需objgraph等工具实测。
Python 的内存管理不是靠“学完第513讲”就能掌握的，它没有编号课程这种东西——官方文档里没有“第513讲”，社区也没有统一课纲。所谓“核心原理”其实就藏在 sys.getrefcount、gc 模块、引用计数机制和循环引用检测这四块里，实战问题基本都出在这几处。
引用计数怎么突然变少了？
Python 绝大多数对象生命周期由引用计数控制，但这个数容易被你忽略的“临时引用”干扰。比如调用 sys.getrefcount(x) 本身就会让 x 的计数+1（因为参数传递产生新引用），返回前再-1；所以看到比预期少1，很可能就是刚查过一次。
- 调试时别依赖单次
sys.getrefcount结果，要对比调用前后的变化趋势 -
id()和is判断的是对象身份，不是内存地址是否复用，不要混为一谈 - 函数参数、列表推导式、lambda 捕获变量都会悄悄增加引用，尤其注意闭包中对大对象的意外持有
gc.collect() 为什么没回收我的对象？
手动调用 gc.collect() 只能触发垃圾回收器清理“可到达性失效”的循环引用，对普通引用计数归零的对象无效——那些早就被即时释放了。如果你的对象还在内存里，大概率是还有别的变量、容器、全局字典甚至 logging 模块的 handlers 在持有着它。
- 先用
gc.get_referrers(obj)查谁在引用它，别急着调gc.collect() - 启用
gc.set_debug(gc.DEBUG_STATS)看每次回收统计，确认是否真有循环引用进入待回收队列 -
gc.disable()后又忘了gc.enable()，会导致后续所有循环引用永久泄漏
用 weakref 防止缓存泄漏，但为什么还是涨内存？
weakref.ref 或 weakref.WeakValueDictionary 能避免强引用延长生命周期，但它们本身不阻止对象创建，也不减少对象构造开销。如果高频创建临时对象再塞进弱引用容器，GC 压力和分配抖动依然存在。
立即学习“Python免费学习笔记（深入）”；
import weakref <p>cache = weakref.WeakValueDictionary()</p><p>def get_data(key): if key not in cache:</p><h1>这里每次 new 一个大对象，即使放进 WeakValueDictionary，也已发生一次分配</h1><pre class='brush:python;toolbar:false;'> cache[key] = HeavyObject() return cache[key]
- 弱引用解决的是“持有导致无法释放”，不是“不该创建却创建了”
- 检查是否在循环/高频路径中反复构造对象，考虑对象池或延迟初始化
-
WeakKeyDictionary对 key 用弱引用，但 value 是强引用——这点常被误读
真正卡住人的从来不是概念多难，而是你看到内存涨了，却不知道该去查 gc.get_objects() 还是 tracemalloc，或者该怀疑是第三方库的 C 扩展绕过了 Python 引用计数。这些边界情况，文档不写，教程不提，只能靠 objgraph + gdb + 实际堆栈来回比对。
