1. 从一个诡异的线上问题说起1.1 内存曲线为什么只涨不跌几年前我负责维护一个Unity手游项目上线三个月后开始收到玩家反馈连续玩三十分钟以上游戏越来越卡最后直接闪退。我们一开始怀疑是资源加载没释放查了AssetBundle的引用计数没问题又怀疑是贴图内存用Profiler一看Texture Memory稳得很。真正诡异的是Mono堆——每次切场景、每次打开关闭UI面板Mono Used Size都会往上跳一截然后永远不回落。当时团队里有人说了句特别典型的话“C#有GC啊怎么可能内存泄漏”这句话我后来在无数个技术群里反复听到。它听起来很有道理但恰恰暴露了一个认知盲区GC能回收的是“不可达对象”而不是“你认为应该被回收的对象”。只要还有一条强引用链从GC Root指向某个对象GC就认为它“还活着”哪怕这个对象在业务逻辑上早就没用了。那次问题的根因最后定位到一个UI面板的事件订阅上。面板关闭时调用了Destroy(gameObject)但面板里的一个C#类实例订阅了全局事件总线的OnPlayerDataChanged事件而事件总线持有这个实例的委托引用。GameObject销毁了但那个C#实例还挂在事件总线的委托链上GC Root事件总线是静态类→ 委托 → 实例 → 实例引用的各种数据整条链都活着。这就是标题里说的“有GC还会内存泄漏”的经典场景。1.2 这篇文章想帮你解决什么我写这篇东西不是想再重复一遍“记得取消订阅”这种正确的废话。我想把这件事拆透GC到底怎么判断对象该不该回收、事件订阅为什么能绕过GC、Unity里哪些写法会制造“隐形强引用”、以及怎么用工具把这类问题揪出来。适合谁看如果你写过C#、用过Unity、知道event关键字但没深究过它的内存行为那这篇就是给你准备的。如果你已经能熟练用Memory Profiler抓快照也可以看看我在排查流程和避坑细节上的经验说不定有能直接抄作业的地方。下面我会从GC的判定逻辑讲起然后落到事件订阅这个具体场景再扩展到Unity里其他几类常见的“伪泄漏”最后给一套可复现的排查流程。全程用大白话加实际代码尽量不堆术语。2. GC的判定逻辑它到底在回收什么2.1 可达性分析不是引用计数很多人对GC的理解停留在“没人引用了就回收”这个说法对但不够精确。C#的GC这里指Unity用的Mono/IL2CPP的Boehm GC以及.NET的GC用的是可达性分析Reachability Analysis不是引用计数。区别在哪引用计数是“每个对象记一个被引用次数归零就回收”。可达性分析是“从一组根对象出发能走到的对象都算活着走不到的全回收”。这个区别直接决定了事件订阅问题的性质。举个例子。对象A订阅了对象B的事件B持有A的委托引用。如果按引用计数A的计数是1不会回收。如果按可达性分析只要B本身是可达的比如B是静态类或者被静态字段引用那么从B出发能走到AA就活着。反过来如果B已经不可达了那B和A会一起被回收哪怕它们互相引用。注意互相引用在可达性分析下不是问题这是它比引用计数强的地方。但“从GC Root可达”这个条件恰恰是事件订阅泄漏的温床——因为事件发布者往往是个长生命周期对象。2.2 GC Root都有哪些要理解泄漏得先知道GC Root是什么。在Unity的C#环境里常见的GC Root包括静态字段静态类的静态变量、单例的静态实例。这是最危险的一类因为它们的生命周期和AppDomain一样长。栈上的局部变量和参数方法执行期间栈上引用的对象算根。CPU寄存器正在被使用的对象引用。GC Handle比如GCHandle.Alloc创建的强句柄或者Unity内部用于跨语言交互的句柄。终结器队列等待执行Finalizer的对象。事件订阅泄漏的典型链条是静态事件总线GC Root→ 委托实例 → 订阅者对象 → 订阅者引用的所有数据。只要事件总线是静态的这条链就永远断不了。2.3 为什么“手动置null”有时没用有人遇到泄漏会尝试obj null但发现内存没降。原因通常是你置null的只是栈上的一个引用但对象还被别的GC Root引用着。比如事件总线还挂着它或者某个静态字典里还存着它。置null只是断开了你手里这条线别的线还在。还有一种情况是对象进了终结器队列。如果类实现了~Finalize析构函数对象第一次GC时不会被立即回收而是进终结器队列等Finalizer线程处理。这期间它算“活着”而且它引用的其他对象也活着。如果Finalizer里又做了阻塞操作堆积起来会造成内存持续上涨。Unity里一般不建议写析构函数就是这个原因。3. 事件订阅为什么能绕过GC3.1 委托的本质是一条引用链C#的event底层是委托Delegate。委托对象内部有两个关键字段_target目标对象和_methodPtr方法指针。当你写publisher.OnEvent subscriber.HandleEvent时实际上创建了一个委托对象它的_target指向subscriber_methodPtr指向HandleEvent方法。这个委托对象被加到publisher的事件委托链上。所以publisher持有委托委托持有subscriber。这是一条实打实的强引用链。只要publisher活着subscriber就别想被回收。3.2 静态事件总线最隐蔽的泄漏源单例或静态事件总线在Unity项目里非常常见因为它解耦方便。但它的生命周期是永久的所以任何订阅它的对象如果不取消订阅就永远不会被回收。我见过一个项目事件总线长这样public static class EventBus { public static event ActionPlayerData OnPlayerDataChanged; public static void RaisePlayerDataChanged(PlayerData data) { OnPlayerDataChanged?.Invoke(data); } }UI面板在OnEnable里订阅在OnDisable里取消订阅。看起来没问题对吧但问题出在有些面板是Destroy而不是SetActive(false)OnDisable确实会调用但如果代码里在OnDestroy之后还有异步回调触发了订阅或者订阅写在了Start里而取消写在了OnDisable里导致次数不匹配就会漏掉。更隐蔽的是匿名lambda订阅。比如EventBus.OnPlayerDataChanged data UpdateUI(data);这种写法你根本没法取消订阅因为lambda生成的委托对象没有保存引用-的时候是另一个委托实例等于没取消。这是新手最容易踩的坑。3.3 生命周期不匹配是根本原因事件订阅泄漏的本质是订阅者的生命周期短于发布者但订阅者没有在销毁时主动断开引用。发布者活得越久静态、单例、长驻Manager泄漏越严重。用一张表把常见组合列一下发布者类型订阅者类型是否泄漏原因静态事件总线UI面板是总线永久存活面板销毁后仍被引用单例Manager普通MonoBehaviour是单例不销毁订阅者被拖住场景内对象A场景内对象B否同场景切场景时一起回收场景内对象A跨场景常驻对象是常驻对象持有场景对象引用短生命周期对象短生命周期对象否一起不可达关键判断标准发布者是否比订阅者活得更久。如果是就必须在订阅者销毁时取消订阅。4. Unity里其他几类“伪泄漏”4.1 协程与闭包捕获协程也是重灾区。StartCoroutine启动的协程如果里面用了lambda或者捕获了外部变量闭包会持有这些变量的引用。如果协程因为StopCoroutine没停干净、或者yield return new WaitUntil的条件永远不满足协程就一直挂着闭包引用的对象也一直活着。我遇到过一个案例一个加载界面用协程做进度条动画协程里捕获了thisMonoBehaviour加载完成后界面Destroy了但协程还在跑因为while循环条件写错了结果整个界面对象被协程的闭包拖住内存里堆了几十个废弃界面。4.2 静态集合只增不减静态的List、Dictionary、Queue如果只往里加不清理就是慢性泄漏。比如对象池如果设计成静态的但Return的时候忘了把对象从“使用中”列表移除或者缓存了对象但从不淘汰内存就会一直涨。还有一种情况是静态字典做缓存但key是对象引用。比如static DictionaryGameObject, Data cacheGameObject销毁了但字典里还留着keykey是强引用GameObject就回收不了。这种要用ConditionalWeakTable或者手动在OnDestroy里移除。4.3 Unity对象与C#对象的“双生命周期”这是Unity特有的坑。UnityEngine.Object比如GameObject、Component有两层C#层的托管对象和C层的原生对象。调用Destroy后原生对象被标记销毁但C#层的托管对象可能还被引用着。这时候你访问它会报MissingReferenceException但它占的托管内存还在直到GC回收。更麻烦的是如果你用 null判断Unity重载了运算符销毁后的对象 null返回true但它在内存里其实还活着。这种“假null”对象如果被静态集合持有就会一直占内存。4.4 事件之外委托、Action、Func的滥用除了event直接持有Action或Func字段也是同样的道理。比如一个Manager里有个public Action OnSomething字段别人往里赋值Manager不清理赋值方就被拖住。这种没有event关键字保护的字段外部还能直接覆盖问题更隐蔽。5. 一套可复现的排查流程5.1 用Memory Profiler抓快照对比Unity的Memory Profiler包不是旧版的Profiler是排查这类问题的核心工具。流程是进入一个干净场景手动GC.Collect()抓一张快照作为基线。执行可疑操作比如打开关闭某个UI面板十次。再GC.Collect()抓第二张快照。对比两张快照看哪些类型的对象数量增加了。如果某个类型比如你的UI面板类数量从1变成11而场景里实际只有1个那说明有10个被泄漏了。点进去看引用链Memory Profiler会显示“谁引用了它”顺着链往上找通常能看到事件总线或静态字段。5.2 引用链怎么读引用链是从GC Root到目标对象的路径。读的时候从Root往下看重点找静态字段EventBus.OnPlayerDataChanged这种。委托的_target指向订阅者。集合的_items数组里面存着对象。如果链上出现了你不认识的静态类那基本就是元凶。我一般会先把所有静态事件总线和单例列出来逐个检查它们的订阅者有没有正确取消。5.3 代码层面的自查清单工具之外代码审查也很重要。我整理了一份自查清单每次Code Review都会过一遍所有事件订阅是否都有对应的-且在同一生命周期方法里比如OnEnable/OnDisable配对有没有用lambda或匿名方法订阅事件如果有改成具名方法。静态集合是否有清理逻辑是否有容量上限协程是否在OnDisable或OnDestroy里StopAllCoroutines单例是否持有场景对象的引用如果有切场景时是否清理有没有类实现了析构函数能否去掉5.4 一个真实的排查记录回到开头那个项目。我用Memory Profiler抓了快照发现PlayerDataPanel类型有23个实例但场景里最多同时存在1个。引用链显示EventBus静态→OnPlayerDataChanged委托 →PlayerDataPanel.OnDataChanged→PlayerDataPanel实例。进一步看代码发现PlayerDataPanel在OnEnable里订阅在OnDisable里取消。但有个分支当玩家数据变化时面板会Instantiate一个子面板子面板也订阅了同一个事件但子面板的取消订阅写在了OnDestroy里而子面板是被Destroy的OnDestroy应该会调用啊再查发现子面板的OnDestroy里有一行提前return了因为某个条件判断导致-没执行。就这么一个return泄漏了23个面板。修复很简单把取消订阅移到OnDisable并且去掉那个提前return。改完后内存曲线立刻平了。6. 实操心得与避坑技巧6.1 订阅与取消要“对称且幂等”最稳的写法是把订阅和取消放在同一对生命周期方法里并且保证幂等。比如private bool _subscribed; private void OnEnable() { if (!_subscribed) { EventBus.OnPlayerDataChanged HandleDataChanged; _subscribed true; } } private void OnDisable() { if (_subscribed) { EventBus.OnPlayerDataChanged - HandleDataChanged; _subscribed false; } }用_subscribed标志位防止重复订阅和重复取消。重复订阅会导致事件触发多次重复取消虽然不报错但逻辑上不干净。6.2 用弱事件模式彻底解决如果项目里事件订阅特别多手动取消容易漏可以考虑弱事件模式Weak Event Pattern。核心思路是让发布者持有订阅者的弱引用WeakReference这样订阅者可以被GC回收回收后发布者自动清理失效的委托。.NET里有WeakEventManagerUnity里可以自己实现一个简化版。原理是用一个包装类持有WeakReference事件触发时检查目标是否还活着不活就移除。代价是每次触发多一次检查性能略降但对于UI事件这种低频场景完全可接受。6.3 匿名lambda的替代方案如果非要用lambda至少把它存成字段private ActionPlayerData _handler; private void OnEnable() { _handler data UpdateUI(data); EventBus.OnPlayerDataChanged _handler; } private void OnDisable() { EventBus.OnPlayerDataChanged - _handler; _handler null; }这样-的时候用的是同一个委托实例能正确取消。但更推荐直接用具名方法可读性更好也不容易出错。6.4 定期做“内存回归测试”我现在的习惯是每个版本提测前跑一次内存回归进主界面、打开所有面板、关闭、切场景、再回来重复十次看Mono堆是否回到基线。如果涨了超过某个阈值比如5MB就停下来查。这个习惯帮我提前拦住了至少三四个泄漏问题比上线后救火划算得多。6.5 常见问题速查表现象可能原因排查方向Mono堆只涨不降事件订阅未取消查静态事件总线的订阅者某类型实例数异常多对象被静态集合持有查静态List/Dictionary切场景后内存不降常驻对象持有场景对象查单例的字段引用协程相关对象不回收协程未停止或闭包捕获查StopCoroutine和lambda销毁后仍报MissingReferenceC#对象被托管引用持有查引用链找静态根7. 最后再聊几句实在的“有GC就不会泄漏”这个说法害过太多人。GC只负责回收不可达对象它不负责帮你断开业务上已经无用的引用。事件订阅、静态集合、协程闭包、单例持有这些都是人为制造的“可达但无用”的引用GC无能为力。我的经验是与其事后用工具抓不如在写代码时就养成习惯凡是必想-凡是静态必想清理凡是lambda必想能不能用具名方法。这三条做到了能挡掉八成以上的托管内存泄漏。工具方面Memory Profiler是必装的快照对比是基本功。刚开始看引用链可能觉得晕多抓几次就有感觉了。另外别迷信“手动GC”GC.Collect()在Unity里调用有性能代价而且它只能回收不可达对象对可达的泄漏对象一点用没有。真正该做的是找到那条多余的引用链把它断开。这个内容其实还能往下挖比如IL2CPP下的GC差异、增量式GC对泄漏表现的影响、以及怎么用WeakReference做对象池的自动清理。以后有机会再展开聊。 
长河君 · 2026/10/2 21:30:26 · 阅读 1.2k Unity C#内存泄漏：GC可达性分析与事件订阅避坑指南
1. 从一个诡异的线上问题说起1.1 内存曲线为什么只涨不跌几年前我负责维护一个Unity手游项目上线三个月后开始收到玩家反馈连续玩三十分钟以上游戏越来越卡最后直接闪退。我们一开始怀疑是资源加载没释放查了AssetBundle的引用计数没问题又怀疑是贴图内存用Profiler一看Texture Memory稳得很。真正诡异的是Mono堆——每次切场景、每次打开关闭UI面板Mono Used Size都会往上跳一截然后永远不回落。当时团队里有人说了句特别典型的话“C#有GC啊怎么可能内存泄漏”这句话我后来在无数个技术群里反复听到。它听起来很有道理但恰恰暴露了一个认知盲区GC能回收的是“不可达对象”而不是“你认为应该被回收的对象”。只要还有一条强引用链从GC Root指向某个对象GC就认为它“还活着”哪怕这个对象在业务逻辑上早就没用了。那次问题的根因最后定位到一个UI面板的事件订阅上。面板关闭时调用了Destroy(gameObject)但面板里的一个C#类实例订阅了全局事件总线的OnPlayerDataChanged事件而事件总线持有这个实例的委托引用。GameObject销毁了但那个C#实例还挂在事件总线的委托链上GC Root事件总线是静态类→ 委托 → 实例 → 实例引用的各种数据整条链都活着。这就是标题里说的“有GC还会内存泄漏”的经典场景。1.2 这篇文章想帮你解决什么我写这篇东西不是想再重复一遍“记得取消订阅”这种正确的废话。我想把这件事拆透GC到底怎么判断对象该不该回收、事件订阅为什么能绕过GC、Unity里哪些写法会制造“隐形强引用”、以及怎么用工具把这类问题揪出来。适合谁看如果你写过C#、用过Unity、知道event关键字但没深究过它的内存行为那这篇就是给你准备的。如果你已经能熟练用Memory Profiler抓快照也可以看看我在排查流程和避坑细节上的经验说不定有能直接抄作业的地方。下面我会从GC的判定逻辑讲起然后落到事件订阅这个具体场景再扩展到Unity里其他几类常见的“伪泄漏”最后给一套可复现的排查流程。全程用大白话加实际代码尽量不堆术语。2. GC的判定逻辑它到底在回收什么2.1 可达性分析不是引用计数很多人对GC的理解停留在“没人引用了就回收”这个说法对但不够精确。C#的GC这里指Unity用的Mono/IL2CPP的Boehm GC以及.NET的GC用的是可达性分析Reachability Analysis不是引用计数。区别在哪引用计数是“每个对象记一个被引用次数归零就回收”。可达性分析是“从一组根对象出发能走到的对象都算活着走不到的全回收”。这个区别直接决定了事件订阅问题的性质。举个例子。对象A订阅了对象B的事件B持有A的委托引用。如果按引用计数A的计数是1不会回收。如果按可达性分析只要B本身是可达的比如B是静态类或者被静态字段引用那么从B出发能走到AA就活着。反过来如果B已经不可达了那B和A会一起被回收哪怕它们互相引用。注意互相引用在可达性分析下不是问题这是它比引用计数强的地方。但“从GC Root可达”这个条件恰恰是事件订阅泄漏的温床——因为事件发布者往往是个长生命周期对象。2.2 GC Root都有哪些要理解泄漏得先知道GC Root是什么。在Unity的C#环境里常见的GC Root包括静态字段静态类的静态变量、单例的静态实例。这是最危险的一类因为它们的生命周期和AppDomain一样长。栈上的局部变量和参数方法执行期间栈上引用的对象算根。CPU寄存器正在被使用的对象引用。GC Handle比如GCHandle.Alloc创建的强句柄或者Unity内部用于跨语言交互的句柄。终结器队列等待执行Finalizer的对象。事件订阅泄漏的典型链条是静态事件总线GC Root→ 委托实例 → 订阅者对象 → 订阅者引用的所有数据。只要事件总线是静态的这条链就永远断不了。2.3 为什么“手动置null”有时没用有人遇到泄漏会尝试obj null但发现内存没降。原因通常是你置null的只是栈上的一个引用但对象还被别的GC Root引用着。比如事件总线还挂着它或者某个静态字典里还存着它。置null只是断开了你手里这条线别的线还在。还有一种情况是对象进了终结器队列。如果类实现了~Finalize析构函数对象第一次GC时不会被立即回收而是进终结器队列等Finalizer线程处理。这期间它算“活着”而且它引用的其他对象也活着。如果Finalizer里又做了阻塞操作堆积起来会造成内存持续上涨。Unity里一般不建议写析构函数就是这个原因。3. 事件订阅为什么能绕过GC3.1 委托的本质是一条引用链C#的event底层是委托Delegate。委托对象内部有两个关键字段_target目标对象和_methodPtr方法指针。当你写publisher.OnEvent subscriber.HandleEvent时实际上创建了一个委托对象它的_target指向subscriber_methodPtr指向HandleEvent方法。这个委托对象被加到publisher的事件委托链上。所以publisher持有委托委托持有subscriber。这是一条实打实的强引用链。只要publisher活着subscriber就别想被回收。3.2 静态事件总线最隐蔽的泄漏源单例或静态事件总线在Unity项目里非常常见因为它解耦方便。但它的生命周期是永久的所以任何订阅它的对象如果不取消订阅就永远不会被回收。我见过一个项目事件总线长这样public static class EventBus { public static event ActionPlayerData OnPlayerDataChanged; public static void RaisePlayerDataChanged(PlayerData data) { OnPlayerDataChanged?.Invoke(data); } }UI面板在OnEnable里订阅在OnDisable里取消订阅。看起来没问题对吧但问题出在有些面板是Destroy而不是SetActive(false)OnDisable确实会调用但如果代码里在OnDestroy之后还有异步回调触发了订阅或者订阅写在了Start里而取消写在了OnDisable里导致次数不匹配就会漏掉。更隐蔽的是匿名lambda订阅。比如EventBus.OnPlayerDataChanged data UpdateUI(data);这种写法你根本没法取消订阅因为lambda生成的委托对象没有保存引用-的时候是另一个委托实例等于没取消。这是新手最容易踩的坑。3.3 生命周期不匹配是根本原因事件订阅泄漏的本质是订阅者的生命周期短于发布者但订阅者没有在销毁时主动断开引用。发布者活得越久静态、单例、长驻Manager泄漏越严重。用一张表把常见组合列一下发布者类型订阅者类型是否泄漏原因静态事件总线UI面板是总线永久存活面板销毁后仍被引用单例Manager普通MonoBehaviour是单例不销毁订阅者被拖住场景内对象A场景内对象B否同场景切场景时一起回收场景内对象A跨场景常驻对象是常驻对象持有场景对象引用短生命周期对象短生命周期对象否一起不可达关键判断标准发布者是否比订阅者活得更久。如果是就必须在订阅者销毁时取消订阅。4. Unity里其他几类“伪泄漏”4.1 协程与闭包捕获协程也是重灾区。StartCoroutine启动的协程如果里面用了lambda或者捕获了外部变量闭包会持有这些变量的引用。如果协程因为StopCoroutine没停干净、或者yield return new WaitUntil的条件永远不满足协程就一直挂着闭包引用的对象也一直活着。我遇到过一个案例一个加载界面用协程做进度条动画协程里捕获了thisMonoBehaviour加载完成后界面Destroy了但协程还在跑因为while循环条件写错了结果整个界面对象被协程的闭包拖住内存里堆了几十个废弃界面。4.2 静态集合只增不减静态的List、Dictionary、Queue如果只往里加不清理就是慢性泄漏。比如对象池如果设计成静态的但Return的时候忘了把对象从“使用中”列表移除或者缓存了对象但从不淘汰内存就会一直涨。还有一种情况是静态字典做缓存但key是对象引用。比如static DictionaryGameObject, Data cacheGameObject销毁了但字典里还留着keykey是强引用GameObject就回收不了。这种要用ConditionalWeakTable或者手动在OnDestroy里移除。4.3 Unity对象与C#对象的“双生命周期”这是Unity特有的坑。UnityEngine.Object比如GameObject、Component有两层C#层的托管对象和C层的原生对象。调用Destroy后原生对象被标记销毁但C#层的托管对象可能还被引用着。这时候你访问它会报MissingReferenceException但它占的托管内存还在直到GC回收。更麻烦的是如果你用 null判断Unity重载了运算符销毁后的对象 null返回true但它在内存里其实还活着。这种“假null”对象如果被静态集合持有就会一直占内存。4.4 事件之外委托、Action、Func的滥用除了event直接持有Action或Func字段也是同样的道理。比如一个Manager里有个public Action OnSomething字段别人往里赋值Manager不清理赋值方就被拖住。这种没有event关键字保护的字段外部还能直接覆盖问题更隐蔽。5. 一套可复现的排查流程5.1 用Memory Profiler抓快照对比Unity的Memory Profiler包不是旧版的Profiler是排查这类问题的核心工具。流程是进入一个干净场景手动GC.Collect()抓一张快照作为基线。执行可疑操作比如打开关闭某个UI面板十次。再GC.Collect()抓第二张快照。对比两张快照看哪些类型的对象数量增加了。如果某个类型比如你的UI面板类数量从1变成11而场景里实际只有1个那说明有10个被泄漏了。点进去看引用链Memory Profiler会显示“谁引用了它”顺着链往上找通常能看到事件总线或静态字段。5.2 引用链怎么读引用链是从GC Root到目标对象的路径。读的时候从Root往下看重点找静态字段EventBus.OnPlayerDataChanged这种。委托的_target指向订阅者。集合的_items数组里面存着对象。如果链上出现了你不认识的静态类那基本就是元凶。我一般会先把所有静态事件总线和单例列出来逐个检查它们的订阅者有没有正确取消。5.3 代码层面的自查清单工具之外代码审查也很重要。我整理了一份自查清单每次Code Review都会过一遍所有事件订阅是否都有对应的-且在同一生命周期方法里比如OnEnable/OnDisable配对有没有用lambda或匿名方法订阅事件如果有改成具名方法。静态集合是否有清理逻辑是否有容量上限协程是否在OnDisable或OnDestroy里StopAllCoroutines单例是否持有场景对象的引用如果有切场景时是否清理有没有类实现了析构函数能否去掉5.4 一个真实的排查记录回到开头那个项目。我用Memory Profiler抓了快照发现PlayerDataPanel类型有23个实例但场景里最多同时存在1个。引用链显示EventBus静态→OnPlayerDataChanged委托 →PlayerDataPanel.OnDataChanged→PlayerDataPanel实例。进一步看代码发现PlayerDataPanel在OnEnable里订阅在OnDisable里取消。但有个分支当玩家数据变化时面板会Instantiate一个子面板子面板也订阅了同一个事件但子面板的取消订阅写在了OnDestroy里而子面板是被Destroy的OnDestroy应该会调用啊再查发现子面板的OnDestroy里有一行提前return了因为某个条件判断导致-没执行。就这么一个return泄漏了23个面板。修复很简单把取消订阅移到OnDisable并且去掉那个提前return。改完后内存曲线立刻平了。6. 实操心得与避坑技巧6.1 订阅与取消要“对称且幂等”最稳的写法是把订阅和取消放在同一对生命周期方法里并且保证幂等。比如private bool _subscribed; private void OnEnable() { if (!_subscribed) { EventBus.OnPlayerDataChanged HandleDataChanged; _subscribed true; } } private void OnDisable() { if (_subscribed) { EventBus.OnPlayerDataChanged - HandleDataChanged; _subscribed false; } }用_subscribed标志位防止重复订阅和重复取消。重复订阅会导致事件触发多次重复取消虽然不报错但逻辑上不干净。6.2 用弱事件模式彻底解决如果项目里事件订阅特别多手动取消容易漏可以考虑弱事件模式Weak Event Pattern。核心思路是让发布者持有订阅者的弱引用WeakReference这样订阅者可以被GC回收回收后发布者自动清理失效的委托。.NET里有WeakEventManagerUnity里可以自己实现一个简化版。原理是用一个包装类持有WeakReference事件触发时检查目标是否还活着不活就移除。代价是每次触发多一次检查性能略降但对于UI事件这种低频场景完全可接受。6.3 匿名lambda的替代方案如果非要用lambda至少把它存成字段private ActionPlayerData _handler; private void OnEnable() { _handler data UpdateUI(data); EventBus.OnPlayerDataChanged _handler; } private void OnDisable() { EventBus.OnPlayerDataChanged - _handler; _handler null; }这样-的时候用的是同一个委托实例能正确取消。但更推荐直接用具名方法可读性更好也不容易出错。6.4 定期做“内存回归测试”我现在的习惯是每个版本提测前跑一次内存回归进主界面、打开所有面板、关闭、切场景、再回来重复十次看Mono堆是否回到基线。如果涨了超过某个阈值比如5MB就停下来查。这个习惯帮我提前拦住了至少三四个泄漏问题比上线后救火划算得多。6.5 常见问题速查表现象可能原因排查方向Mono堆只涨不降事件订阅未取消查静态事件总线的订阅者某类型实例数异常多对象被静态集合持有查静态List/Dictionary切场景后内存不降常驻对象持有场景对象查单例的字段引用协程相关对象不回收协程未停止或闭包捕获查StopCoroutine和lambda销毁后仍报MissingReferenceC#对象被托管引用持有查引用链找静态根7. 最后再聊几句实在的“有GC就不会泄漏”这个说法害过太多人。GC只负责回收不可达对象它不负责帮你断开业务上已经无用的引用。事件订阅、静态集合、协程闭包、单例持有这些都是人为制造的“可达但无用”的引用GC无能为力。我的经验是与其事后用工具抓不如在写代码时就养成习惯凡是必想-凡是静态必想清理凡是lambda必想能不能用具名方法。这三条做到了能挡掉八成以上的托管内存泄漏。工具方面Memory Profiler是必装的快照对比是基本功。刚开始看引用链可能觉得晕多抓几次就有感觉了。另外别迷信“手动GC”GC.Collect()在Unity里调用有性能代价而且它只能回收不可达对象对可达的泄漏对象一点用没有。真正该做的是找到那条多余的引用链把它断开。这个内容其实还能往下挖比如IL2CPP下的GC差异、增量式GC对泄漏表现的影响、以及怎么用WeakReference做对象池的自动清理。以后有机会再展开聊。