开场凌晨两点，你盯着 Profiler 上那条倔强上扬的内存曲线，心里清楚——这不是一次性的内存爆炸，也不是忘了Destroy的低级失误。这条曲线像慢性病一样，每隔几分钟往上抬一点台阶，中间偶尔回落，但最低点一次比一次高。跑了一夜的战斗服，内存从开服时的 800MB 涨到 2.3GB，GC 越来越频繁，帧率却还能撑住。玩家没掉线，服务器没崩，可运营说过几天就要炸。这种「慢性内存泄漏」最折磨人：它不像野指针那样当场崩溃，而是温水煮青蛙，等你意识到时，内存池已经被啃得千疮百孔。这篇文章讲怎么把这只「慢刀子凶手」揪出来。重点不是罗列 API，而是三件事：为什么 GC 时代还会泄漏（原理）、采什么样的数据、从曲线形状里读出什么线索。一、先建立心智模型：托管堆里什么叫「泄漏」1.1 有 GC 为什么还会漏很多同学的困惑是：C# 有垃圾回收，不存在「忘了 free」的问题，那泄漏从哪来？关键在于 GC 的判定标准是可达性（Reachability），不是「你还有没有用」。GC 从一组根（静态字段、当前栈上的局部变量、GC Handle 等）出发做标记，凡是顺着引用链能摸到的对象，一律不回收。于是泄漏的定义变成了：对象逻辑上已经死了，但还有一根你没意识到的引用链把它挂在根上。GC 没有错杀，是你忘了放手。// 教科书级案例：事件订阅不注销 public