★ FEATURED ARTICLE 1. 先把“销毁”这件事说透你知道的 Destroy 可能理解偏了很多刚接触 Unity3D 的开发者看到“销毁物体”这四个字脑子里闪过的第一反应就是Destroy(gameObject)然后以为物体彻底没了内存也释放了。实际上这里有个很大的认知偏差Unity 引擎里的“销毁”和 C# 里的“释放内存”根本不是一回事。Unity 的 GameObject 和 Component 在 C# 侧其实是一个托管壳它背后对应的是引擎原生侧的一个对象。调用Destroy只是告诉引擎“这个物体可以标记为销毁了”引擎会在合适的时机把原生侧的对象清掉而 C# 侧这个对象引用如果还在你要去访问它就会抛一个非常有名的异常——MissingReferenceException。这个异常的出现本身就暴露了 Unity 销毁机制的核心引用还在对象没了。很多新手在这个地方会一脸懵说“我已经销毁它了为什么代码里还能拿到引用”其实拿到的是引用而不是对象。这就好比你去餐厅订了一份菜服务员告诉你菜已经撤掉了但菜单还留在你手里——你对着菜单喊“我的菜去哪了”永远得不到回应。搞清楚这个底层逻辑之后再回头看“三种销毁方式”就清楚得多。我在实际项目中接触到的真正值得拿到台面上来讨论的其实是三条完全不同的路线一种是游戏运行时最常用的Destroy一种是编辑器开发阶段会碰到的DestroyImmediate还有一种是被很多人忽略但实际上是性能优化王牌的方式——SetActive(false)配合对象池。严格来说第三种不是销毁而是“隐藏并复用”但在实际开发中它承担的任务往往和销毁一模一样。这篇文章就是把我这几年在项目里和这三种方式打交道的过程中踩过的坑、绕过的弯以及最终沉淀下来的一套选型逻辑一次性说清楚。先给出一个结论性的对比表方便你对整体轮廓有数方式生效时机触发回调对象是否还在内存典型使用场景Destroy()当前帧结束OnDestroyC#引用残留原生对象已清游戏运行时删除角色、子弹、掉落物DestroyImmediate()调用后立即OnDestroy立即清除编辑器脚本、菜单工具、资源处理SetActive(false)调用后立即OnDisable不触发OnDestroy完整保留对象池、UI隐藏、可复用物体暂存这张表你多看一眼后面所有细节都是围绕这三行展开的。2. Destroy 的帧延迟之谜为什么你点了鼠标物体还在原地站着2.1 从一次灵异子弹消失事件说起曾经在一次射击类的 Demo 开发里策划反馈说“子弹打到墙上之后明明已经执行了销毁逻辑但画面里子弹还会保持一个姿势悬在墙上过一帧才消失。”我当时第一反应是销毁的代码没执行排查了半天发现逻辑没有任何问题——Destroy调用之后物体只是被标记了销毁状态真正从场景里移除要等到当前帧的渲染结束之后。这里要展开说一下 Unity 的帧生命周期。Unity 每一帧大致会经历FixedUpdate如果有物理需求、Update、LateUpdate、增量时间计算、物理模拟、动画求值、渲染最后才执行被标记的销毁操作。Destroy本质上是一个“排队销毁”操作你调用了它它不会立刻打断当前的帧流程。这样做是刻意的如果在Update的循环中间把物体直接从场景树里摘除引擎底层的很多遍历逻辑会瞬间失控尤其涉及到物理系统、渲染批次、光照计算整个场景树的一致性会被破坏。所以 Unity 的设计者选择把销毁操作压到帧末统一处理。这个机制带来的直接后果就是在同一帧内即使你已经调用了Destroy(go)紧接着去读取go.transform.position、go.name依然能拿到正常的值。这一点在调试惯性思维下很容易被忽略很多人以为调用Destroy之后引用立刻失效于是在代码里写Destroy(go); if(go ! null)结果条件判断还成立逻辑就出问题了。2.2 一个学废的 OnDestroy 回调时序OnDestroy这个回调在课程里讲过、文档里写过但真正把它用对的人并不多。它是 MonoBehaviour 生命周期里的最后一个回调在物体被销毁或者场景切换的时候触发。这句话听起来很简单但触发顺序里有很多微妙的细节。第一个坑OnDestroy不是帧末统一调用的而是在这个物体被“销毁”的那个时刻调度出来的。如果两个物体在同一个帧都被销毁它们的OnDestroy调用顺序是不确定的绝对不能依赖它来判断先后关系。曾经在一个多人在线类的项目中两个玩家在同一个帧各自走了销毁流程其中一个物体的OnDestroy里读取了另一个物体的状态结果拿到的是已经被清掉一半的数据查了三天最后锁定的就是这个不确定顺序的问题。第二个坑OnDestroy里不能保证父节点或者其他兄弟节点还活着。因为 Unity 销毁一个父物体时会连带销毁子物体这个连带销毁的顺序是自外向内还是自内向外并没有一个稳定的官方契约。我在一些版本里实测父物体的OnDestroy会在子物体之前触发这导致在父物体的OnDestroy里去遍历访问子物体组件稍有不慎就会访问到已被销毁的内容。第三点Destroy还有一个带延迟参数的版本Destroy(gameObject, 2f)表示两秒后再销毁。这个接口其实底层实现很有意思Unity 会起一个内部计时机制在指定时间后把这个物体移入销毁队列。很多人用这个接口来实现“受击后闪白一下再消失”“播放完死亡动画再销毁”的效果但注意这期间计时是真实的绝对时间不是游戏帧时间如果你的游戏有暂停逻辑暂停期间这个销毁倒计时并不会暂停。实战提示在项目里如果多个地方会调用同一个物体的销毁逻辑建议统一封装一个Die()方法在方法内做一层防重入保护。比如用一个私有布尔变量一旦进入销毁流程就置为 true防止同一帧里被碰撞回调、子弹脚本、技能脚本重复调用Destroy浪费那一帧的微小开销还是小事关键是会引发OnDestroy里清理逻辑的幂等性问题。2.3 Destroy 之后引用还在这是好是坏我见过一些程序设计得比较严谨的同学销毁之后会把引用手动置空比如Destroy(go); go null;这种做法本身没有错但要理解你置空的其实是 C# 侧的托管引用对引擎原生侧的对象没有任何额外影响引擎该什么时候清理还是什么时候清理。然而手动置空有一个好处之后如果再有人使用这个变量访问到的是安全的 null会抛出普通的NullReferenceException而不是那个更难排查的MissingReferenceException。这两种异常的区别值得展开一下。普通空引用是变量本身没有指向任何对象MissingReferenceException是引用曾经真实存在过但背后的原生对象已经被引擎销毁Unity 给出了一条带判断的“伪空引用”——它会印出“Object 一类的引用已失效”的日志但代码里if (obj ! null)确实返回 false因为 Unity 重载了操作符让已销毁对象的比较结果等于 null。这个重载帮了很多忙但也埋了一些坑在Dictionary或List里存的对象如果被销毁了list.Contains(obj)这类操作不会自动认为它不存在你依然要手动清理列表。我个人的建议是能手动置空就置空尤其当一个引用被多个脚本共享的场景宁可多写一行 null也别把判断依赖在 Unity 的重载比较上。项目代码的健壮性往往就是这么一个小习惯撑起来的。3. DestroyImmediate 的“危险”诱惑编辑器里有多爽运行时就有多痛3.1 它到底解决了什么问题DestroyImmediate字面意思就是“立即销毁”调用后马上把对象从场景中摘除不排队、不等帧末。听起来比Destroy直接多了为什么官方文档里反反复复强调“编辑器环境下使用”我最早不理解后来在一次实际事故里彻底明白了。那次是在做地图编辑器工具需要批量删除场景里的一批路标物体。我图省事直接在一个菜单按钮的回调里写了一个循环调用了DestroyImmediate。编辑器模式下跑得很欢我也没在意。后来有同事在游戏运行的时候误触发了一个类似的工具路径结果游戏当场崩溃——不是报错是直接崩。查了半天根源在于运行时的渲染管线正在遍历场景里的 Renderer我把物体从场景树里硬拽出去了没有给引擎内部数据结构留出同步窗口。这句话可以总结成一条铁律运行时用Destroy编辑器工具用DestroyImmediate。这不是性能考量而是引擎把DestroyImmediate定位为“编辑器开发模式才会用到的例外手段”它在调度层面绕过了引擎设计的帧末统一清理机制代价是所有依赖帧内一致性的系统都会和你翻脸。物理系统在一步模拟中间发现碰撞体凭空消失、动画系统正在播放的骨骼节点被抽走、寻路系统遍历到一半节点断了——这些场景都可能触发不可预期的行为甚至是崩溃。3.2 从编辑器到运行时的连环翻车现场有一个很经典的翻车模式在循环里用DestroyImmediate遍历删除子物体。foreach (Transform child in transform) { DestroyImmediate(child.gameObject); }这是我见过出现频率最高的错误写法。原因在于DestroyImmediate是真正的立即删除它在删除一个子物体的同时父物体的子物体列表已经发生了变化foreach 迭代器是基于原始快照的继续往下走要么报了InvalidOperationException要么漏删或者把不该删的删了。哪怕你换成 for 循环配合childCount动态判断也一样容易踩坑for (int i 0; i transform.childCount; i) { DestroyImmediate(transform.GetChild(i).gameObject); }这里每删除一个子物体子物体数量就减一下标 i 递增加上 childCount 递减相当于每次跳过了一个索引最终一定会留下没有删除干净的物体。正确写法有两种一种是倒序删除for (int i transform.childCount - 1; i 0; i--) { DestroyImmediate(transform.GetChild(i).gameObject); }另一种是先把子物体列表拷贝出来再删ListGameObject list new ListGameObject(); foreach (Transform child in transform) list.Add(child.gameObject); foreach (GameObject go in list) DestroyImmediate(go);不要小看这种代码细节我在不少项目代码 review 里都见过类似的 bug。编辑器工具写得再顺手一旦引入到自动化流程或者批处理管线里这种“漏删一半”的问题足够折腾一个下午。3.3 DestroyImmediate 的正确姿势写在自定义菜单和扩展面板里说到正确的打开方式最常规的用途有这几类第一类自定义菜单操作。你在菜单栏或者Assets右键菜单里注册一个MenuItem处理所选资源或层级物体的批量操作这类场景天然就是编辑器模式调用DestroyImmediate完全合理。比如我之前写过一个资源清理工具把场景里所有名字带_TMP前缀的临时物体一键删除用的就是DestroyImmediate。第二类自定义 Inspector 面板里的按钮回调。你在编辑器的检查器里画了一个按钮点击后要删除某些对象或重建子物体这类操作在编辑器模式下执行使用DestroyImmediate路径才能让你立刻在编辑器界面中看到结果。如果用Destroy它会等到当前帧末编辑器模式下的“帧”节奏和运行时不一样容易给人一种“点了没反应”的错觉。第三类资源导入后处理。实现AssetPostprocessor的OnPostprocessAllAssets回调里如果需要清理导入过程中产生的临时物体也必须使用DestroyImmediate因为整个资源导入流程发生在编辑器内部走的并不是运行时那一套帧循环。在写这类编辑器代码时还有一个小经验批量操作前调用Undo.RecordObject记录状态这样用户可以在编辑器里 CtrlZ 撤销。如果用了DestroyImmediate但没有纳入撤销系统用户手一抖删了 30 个关卡配置地标后悔药都没得吃。配合Undo.DestroyObjectImmediate接口可以自动记录销毁操作这个细节我踩过坑之后每次写编辑器删物体工具都会下意识带上。4. SetActive(false)用“假销毁”换真性能——对象池思路的起点4.1 隐藏不等于销毁但很多时候我们只需要隐藏第三种方式严格来说不是“销毁”而是SetActive(false)。为什么它会被放进“销毁物体”的讨论里因为在游戏运行时的真实开发中很多所谓的“销毁”需求其实只需要“看不见且不参与逻辑”即可。子弹打到目标后消失、怪物死亡后尸体消失、掉落物被捡起后消失——这些场景里你是否真的需要把物体从场景里移除大多数情况下不需要。这里就必须提到“激活”这个概念的两个层面activeSelf是物体自身的激活状态activeInHierarchy是结合所有父节点激活状态后的最终结果。gameObject.SetActive(false)会把activeSelf置为 false如果你的父物体还处于激活状态此时物体的activeInHierarchy也是 false它就会停止渲染、停止物理模拟、停止大部分组件逻辑。注意我说的是“大部分”——例如Transform这种基础组件不受激活状态影响你在代码里依然可以移动一个SetActive(false)物体的位置评论。对性能的观察也很直观场景里有 100 个敌人尸体如果全部放在场景里挂着即使角色不运动、材质不闪烁、逻辑不执行单是渲染管线的剔除计算和内存占用就是白白浪费。SetActive(false)之后这些物体完全退出渲染队列和物理计算几乎不产生每帧开销但你随时可以SetActive(true)把它“复活”——这比重新实例化一个物体快多了。4.2 从隐藏到对象池我是怎么把实例化开销降下来的说到对象池就不得不提 Unity 里Instantiate的开销问题。每实例化一个物体引擎要在托管的场景图上创建一个新的节点分配组件、执行Awake、OnEnable等回调还要同步渲染数据的资源引用。频繁创建销毁GC 压力大是一方面更麻烦的是在一段时间内生成大量子弹或特效时帧率抖动会非常明显。典型的对象池实现是这么做的在游戏启动时预创建一批可用物体统一放容器里挂起需要时从池中取一个SetActive(true)并重置位置和状态不需要时SetActive(false)丢回池子而不是Destroy。这套思路很多项目都在用但实现细节里有一些比“取出一个对象”要隐蔽得多的坑。第一个坑是物体状态的重置。你在物体被使用的那一帧给它设置了速度、朝向、颜色池子回收的时候没有清理干净下一次取出它就是带着旧状态出来的。我最开始写射击 Demo 的时候偷懒只在取出的接口里做了重置回收时没管结果就出现了子弹飞出去带着上一个敌人身上的挂载特效这种诡异的画面。后来我把重置逻辑统一放在回收接口里约定“回池即回收所有外部状态”再也没出过这类问题。第二个坑是父子节点关系。物体从池子取出后有时需要挂到某个父节点下面回收时如果不把这个父子关系剥离清楚物体就一直挂在你游戏世界里某个角色的子节点上SetActive(false)虽然看不到它但它的transform依然跟着父节点运动内部坐标已经混乱。所以进出池子的接口里一定要处理好transform.SetParent(null)或者统一管理挂载节点。第三个坑是OnDisable和OnEnable的跟踪问题。SetActive(false)会触发一次OnDisableSetActive(true)会触发OnEnable这两个回调配合对象池非常关键。我习惯把“回池清理”的逻辑写在OnDisable里而不是回收接口里因为任何被SetActive(false)的物体都会自动触发它比手动调用更不容易遗漏。实战体会对象池不是万灵药。如果你的物体生命周期很长比如场景里那个始终存在的中型装饰物一次性创建就不再销毁完全没有池化必要。池化只有在“高频创建、短生命周期”的场景才有明显的收益典型是射击项目的子弹、技能特效、刷怪系统的敌人。判断是否需要池化可以看这个物体一秒钟内是否会创建超过几十个——如果攒不到这个量级先别急着池化把代码可读性保住更重要。4.3 隐藏物体不能触发的回调该清理的东西别指望引擎SetActive(false)不会触发OnDestroy这一点很多人容易混淆。我见过有同事把资源释放、事件退订的逻辑写在OnDestroy里然后通过SetActive(false)想实现“物体用完就清理”结果发现物体的资源和事件绑了一次又一次Never 释放产生了内存泄漏。正确的设计思路是如果你把SetActive(false)当成“暂时不用”来处理那么和生命周期相关的清理逻辑比如协程中止、音频播放停止、UI 事件退订应该写在OnDisable里如果你确实要彻底移除这个物体那才把它写在OnDestroy里并且配合Destroy调用。有一类不同场景OnDisable里不要访问别的物体因为SetActive(false)的瞬间你的父节点可能还在正常的激活状态但兄弟节点可能已经先一步被关掉了。这个话题又回到了 Unity 回调时序不保证的问题上。我的原则是OnDisable里只清理自己身上的资源不读外部状态可以省掉不少莫名奇妙的 null 报错。5. 销毁路径上的经典事故组件泄漏、回调顺序和空引用5.1 父物体销毁时子物体去哪儿了聊完三种方式各自的特性再来看几个我在实际项目中高频遇到的综合性事故这些事故往往不是单一 API 用错了而是对销毁语义的理解和回调顺序的假设出了问题。最经典的一类是父物体销毁连带子物体销毁但你对子物体的引用还留在别处。假设你有一个敌人对象敌人体内挂了一个血条 UI 的脚本引用这个脚本引用指向的是一个子物体上的 UI 组件。敌人死亡时你Destroy(enemy)血条 UI 脚本里保存的那个组件引用不会自动变成 null——它指向的是一个已经被连带销毁的子物体等你下一次给血条赋值时MissingReferenceException就出现了。这其实是开发里很典型的“悬挂引用”问题解决方式也很直接要么在敌人的销毁入口明确通知所有外部引用者清理引用要么让血条脚本自身监听一个自定义的死亡事件。5.2 协程没有停销毁之后还在跑第二个高频事故是协程和销毁的配合。Unity 协程挂在MonoBehaviour上运行当你Destroy这个物体时协程不会立即被强制中断它有它自己的清理节奏。如果协程体里有一个yield return new WaitForSeconds(2f)物体已经销毁了协程还在继续计时等它醒来继续执行transform.position ...就会炸一个MissingReferenceException。这个报错时机极其迷惑错误发生在几秒钟之后和你当初销毁的代码完全不在一个上下文里排查起来真的头疼。我后来总结出一套规避办法凡是会持续运行的协程统一放在一个独立的“管理器”类里而不是挂在会被销毁的物体上。比如倒计时、技能持续效果这些全局逻辑可以让一个单例类管理子物体被销毁不影响管理器的协程运行。如果实在要挂在物体上那么在销毁前主动调用StopAllCoroutines()把协程生命周期和物体生命周期绑死在同一个入口。5.3 销毁和物理回调的交叉污染第三种事故和物理引擎相关。在OnCollisionEnter或OnTriggerEnter回调里销毁碰撞对象看起来是很自然的需求比如子弹命中怪物后把自己和怪物都销毁。但这里有一个隐蔽的时序物理回调发生在物理模拟阶段你销毁物体时Unity 物理引擎内部的碰撞数据结构正处于迭代状态物体被标记销毁后物理引擎可能会在下一轮计算中拿到不一致的数据。我在项目里遇到的一个典型表现是某些子弹明明已经销毁但物理回调里依然会触发一次额外的碰撞判断代码再次尝试销毁已经标记销毁的物体引发一场连锁的日志风暴。这种场景下的安全写法是物理回调里不回销毁只是打一个销毁标记然后在下一帧Update的开头统一执行销毁逻辑。用一帧的延迟换稳定这非常有价值。void OnCollisionEnter(Collision collision) { if (collision.gameObject.CompareTag(Boss)) { _pendingDestroy true; } } void Update() { if (_pendingDestroy) { _pendingDestroy false; GameManager.Instance.SpawnExplosion(transform.position); Destroy(gameObject); } }我知道有经验的读者会问为什么不用Destroy自带的延迟参数Destroy(gameObject, 0.1f)其实也可以但我个人更喜欢显式标记法因为它的流向更直白而且方便你在同一个帧内统一处理多个物件的销毁逻辑比如同时触发多个连锁爆炸后统一收尾。6. 三种方式选型思路按场景做决策不迷信单一方案6.1 一个决策流程示例写到这里三种方式的机制、原理、坑都聊过了最该给出一套可以照做的选型方案。我自己的项目里基本上遵循这样的判断流程先问自己一个问题这个物体以后还会不会再被用到如果不会再被用到而且它是运行时逻辑生成的物体子弹、敌人、掉落物、临时 UI使用Destroy。如果用完可能还会复用而且复用的频率很高射击子弹、刷怪小兵、弹幕特效使用SetActive(false)做对象池。如果这段代码只在编辑器模式下执行且需要立刻看到结果工具脚本、菜单、资源处理使用DestroyImmediate。这个流程看起来简单但实操里经常会发生混淆。举个例子关卡切换时你会有一个场景清理逻辑把当前关卡的所有怪物和掉落物清掉。很多人会下意识选择Destroy循环删除但如果你马上要跳转到下一个场景而且下一个场景会重新加载这些资源更好的方案可能是直接让整个场景走场景卸载流程连逐物体销毁都省了。过度销毁反而会造成一帧里的 GC 开销激增和卡顿。6.2 再补充一个取舍点Container 容器和事件监听的清理时机一个容易忽略的细节是不管用哪种方式只要某个物体持有DontDestroyOnLoad属性它就不会被场景卸载连带销毁。这本身没问题但配合上事件监听就会出问题。比如你有一个全局事件系统某个临时 UI 在OnEnable时订阅了一个“角色血量变化”事件在OnDisable时退订。如果你用Destroy销毁这个 UI按照生命周期OnDisable会在销毁时被调用退订逻辑会执行这是对的。但如果你用SetActive(false)让 UI 隐藏它触发OnDisable退订。然后又SetActive(true)恢复显示它触发OnEnable重新订阅。这套逻辑如果只在Start里订阅了一次那么第一次进场景显示后切隐藏再恢复显示时——你会发现 UI 已经收不到事件了。这个问题的根源在于完全混淆了“销毁”和“隐藏”的生命周期语义。在实际写代码的时候我一般会在OnEnable和OnDisable里成对写订阅和退订这样无论对象是隐藏还是销毁事件系统都不会出现重复订阅或者漏退订的问题。6.3 一个小型完整的封装示例最后分享一个我在项目里常用的一个轻量封装把“销毁并清理”的逻辑收敛到一个工具类里public static class GoHelper { public static void SafeDestroy(GameObject go, bool detachFirst false) { if (go null) return; if (detachFirst) { go.transform.SetParent(null); } go.StopAllCoroutines(); foreach (var handler in go.GetComponentsInChildrenIManagedDestroy(true)) { handler.OnBeforeDestroy(); } Object.Destroy(go); } }接口IManagedDestroy可以由需要自行清理的组件实现在真正销毁前统一走一遍清理回调。这样每个组件只需要管好自己那点状态不需要把OnDestroy里的事件退订逻辑和资源释放逻辑写得纠缠不清。类似的思路也适用于对象池的回收回收前遍历组件调用同一个清理接口避免忘掉某个脚本的暂存状态。代码本身不复杂但在项目里长期维护时这类“统一销毁入口”的价值会随着项目代码量的增加被放大。我自己在实际操作中最深的一点体会是大多数销毁相关的 bug 都不是因为销毁方式选错了而是因为你没有搞清楚这个物体被销毁之后还有哪些引用、哪些回调、哪些协程在默默惦记着它。清理不干净才是事故的源头。回到最开始那张比较表三种方式各自适合的场景以及它们背后的生命周期逻辑——把这张表刻进脑子里再碰到任何“物体消失了但有诡异残留行为”的 case至少你能第一时间判断出问题出在哪一层。
阅读完成 · 觉得有帮助？
