1. 项目概述：一个看似简单却暗藏玄机的需求

在Unity开发中，我们经常需要管理一组脚本，让它们在特定游戏对象激活或失活时，自动加入或离开某个“执行列表”。比如，你有一个全局的“更新管理器”，负责每帧驱动所有需要执行Update逻辑的脚本；或者你有一个“事件广播器”，需要动态地向活跃的物体发送消息。这个需求的核心，就是在OnEnable和OnDisable这两个生命周期函数里，优雅地完成脚本实例的注册与注销。

听起来很简单，对吧？不就是在一个列表里Add和Remove吗？但实际做起来，新手甚至一些有经验的开发者都会踩进不少坑里。对象意外销毁导致的空引用、重复注册引发的逻辑错误、在错误的时机进行注册导致数据不同步……这些问题如果不处理好，轻则功能异常，重则直接崩溃。今天，我就结合自己踩过的坑和总结的最佳实践，来详细拆解这个“在物体激活/失活时从脚本列表中添加或删除”的完整解决方案。无论你是正在构建一个自定义的游戏框架，还是优化现有代码的管理逻辑，这篇文章都能给你提供可直接复用的代码和清晰的避坑指南。

2. 核心设计思路与架构解析

2.1 为什么不用简单的静态列表？

最直观的想法是创建一个静态的List<MyScript>，然后在MyScript的OnEnable和OnDisable里直接操作这个列表。

public class UpdateManager : MonoBehaviour { public static List<MyScript> activeScripts = new List<MyScript>(); } public class MyScript : MonoBehaviour { private void OnEnable() { UpdateManager.activeScripts.Add(this); } private void OnDisable() { UpdateManager.activeScripts.Remove(this); } }

这个方案在Demo里或许能跑，但在实际项目中是极其脆弱的，主要原因有三点：

1. 线程安全问题：Unity虽然主逻辑是单线程的，但OnEnable/OnDisable的调用时机复杂，特别是在场景加载、对象池频繁启用/禁用时，可能引发对列表的并发修改，导致异常。
2. 空引用与重复项：如果脚本所在的GameObject被直接Destroy，OnDisable可能不会被调用（取决于销毁顺序），导致列表中残留“僵尸”引用。下次遍历列表时访问它就会抛出MissingReferenceException。同样，如果启用/禁用逻辑有BUG，可能导致同一个实例被多次加入列表。
3. 缺乏控制与扩展性：静态列表是全局可变的，任何代码都能随意修改它，破坏了封装性。当我们需要根据脚本类型、优先级进行分组管理时，静态列表就显得力不从心。

因此，我们的设计目标不仅仅是实现功能，更要实现健壮性、可维护性和性能。

2.2 稳健的双缓冲列表与接口驱动设计

一个经过实战检验的设计模式是使用“双缓冲列表”配合“接口”：

1. 定义接口：创建一个公共接口（例如IManagedBehaviour），规定需要被管理的脚本必须实现的方法（如ManagedUpdate）。
2. 管理器使用双列表：管理器内部维护两个列表：一个用于注册/注销操作（registrationList），一个用于实际迭代（activeList）。在每帧的固定点（如LateUpdate），将注册列表的变化同步到活跃列表。这避免了在迭代过程中修改集合导致的异常。
3. 弱引用或唯一标识：为了防止残留引用，管理器不应直接持有脚本的强引用。可以使用WeakReference（但Unity对象比较特殊），或者更常见的，让脚本在注册时提供一个唯一的标识符（如实例ID），管理器只保存这个ID和接口引用，并在每次使用前检查对象是否已被销毁。

这种架构将管理逻辑集中化，脚本只需关心“我是谁”和“我是否活跃”，而管理器负责“如何高效安全地执行所有活跃的脚本”。

// 定义需要被管理的脚本接口 public interface IManagedBehaviour { void ManagedUpdate(); int InstanceID { get; } // 用于唯一标识和清理 }

3. 核心细节解析与实操要点

3.1 脚本生命周期与注册时机的精确把控

OnEnable和OnDisable是Unity MonoBehaviour的生命周期函数，但它们被调用的时机有细微差别，理解这些差别是避免BUG的关键。

• OnEnable: 在脚本实例被创建并且游戏对象处于激活状态时调用。注意：如果脚本被添加到已激活的游戏对象上，它会立即调用OnEnable。如果游戏对象本身未激活，即使脚本组件被启用，OnEnable也不会被调用，直到游戏对象被激活。
• OnDisable: 在游戏对象变为非激活状态或脚本组件被禁用时调用。当游戏对象被销毁时，OnDisable会在OnDestroy之前被调用。

关键陷阱：假设你的管理器在Awake中初始化了自己的静态实例。如果一个脚本的OnEnable在管理器Awake之前执行了，它尝试向一个为null的静态实例注册，就会导致空引用异常。这就是常见的“脚本执行顺序”问题。

解决方案：不要在OnEnable中直接访问管理器实例。可以采用“延迟注册”机制，或者让管理器在Awake阶段确保自己是最早被初始化的之一（通过Unity的Script Execution Order设置）。

// 在脚本中，安全的注册方式 public class MyManagedScript : MonoBehaviour, IManagedBehaviour { private void OnEnable() { // 不直接调用，而是标记自己需要注册 // 管理器会在每帧开始时处理所有待注册的脚本 BehaviourManager.Instance?.ScheduleRegister(this); } private void OnDisable() { // 同样，标记自己需要注销 BehaviourManager.Instance?.ScheduleUnregister(this); } }

3.2 管理器的实现：线程安全与性能考量

下面是一个简化但健壮的管理器核心实现：

using System.Collections.Generic; using UnityEngine; public class BehaviourManager : MonoBehaviour { private static BehaviourManager _instance; public static BehaviourManager Instance { get { if (_instance == null) { // 懒加载模式，也可以使用[RuntimeInitializeOnLoadMethod]在游戏启动时创建 var go = new GameObject("BehaviourManager"); _instance = go.AddComponent<BehaviourManager>(); DontDestroyOnLoad(go); } return _instance; } } // 双缓冲列表：一个用于添加/删除操作，一个用于遍历 private List<IManagedBehaviour> _behavioursToAdd = new List<IManagedBehaviour>(); private List<IManagedBehaviour> _behavioursToRemove = new List<IManagedBehaviour>(); private List<IManagedBehaviour> _activeBehaviours = new List<IManagedBehaviour>(); // 用于快速查找和避免重复的字典（Key为InstanceID） private Dictionary<int, IManagedBehaviour> _behaviourMap = new Dictionary<int, IManagedBehaviour>(); private object _lock = new object(); // 简单的锁，用于保证线程安全 public void ScheduleRegister(IManagedBehaviour behaviour) { lock (_lock) { _behavioursToAdd.Add(behaviour); } } public void ScheduleUnregister(IManagedBehaviour behaviour) { lock (_lock) { _behavioursToRemove.Add(behaviour); } } private void LateUpdate() { // 1. 处理注销 lock (_lock) { if (_behavioursToRemove.Count > 0) { foreach (var behaviour in _behavioursToRemove) { // 从活跃列表和映射表中移除 _activeBehaviours.Remove(behaviour); _behaviourMap.Remove(behaviour.InstanceID); } _behavioursToRemove.Clear(); } // 2. 处理注册 if (_behavioursToAdd.Count > 0) { foreach (var behaviour in _behavioursToAdd) { // 检查是否已销毁或已注册 if (behaviour == null || _behaviourMap.ContainsKey(behaviour.InstanceID)) continue; _activeBehaviours.Add(behaviour); _behaviourMap.Add(behaviour.InstanceID, behaviour); } _behavioursToAdd.Clear(); } } // 3. 遍历执行活跃脚本的更新逻辑 // 注意：这里遍历的是_activeBehaviours，它在步骤1和2中已被安全更新 for (int i = 0; i < _activeBehaviours.Count; i++) { var behaviour = _activeBehaviours[i]; // 执行前的最终安全检查 if (behaviour != null) { behaviour.ManagedUpdate(); } else { // 如果发现空引用（理论上经过上述步骤应该很少），安排在下帧移除 lock (_lock) { _behavioursToRemove.Add(behaviour); } } } } private void OnDestroy() { // 清理静态实例，防止内存泄漏 if (_instance == this) { _instance = null; } } }

这段代码的几个关键点：

1. 双缓冲与锁：_behavioursToAdd和_behavioursToRemove是缓冲列表，所有注册/注销请求先放在这里。在LateUpdate中，在一个lock块内将缓冲列表的变化应用到_activeBehaviours和_behaviourMap。这保证了修改操作是线程安全的（尽管Unity主线程单线程，但此设计能防止其他协程或异步操作带来的意外）。
2. 字典去重：使用_behaviourMap（以InstanceID为Key）来快速判断一个脚本是否已经注册，避免重复添加。
3. 延迟清理：在遍历_activeBehaviours执行ManagedUpdate时，如果发现某个引用意外为null，会将其加入待移除列表，在下一帧清理。这是一个防御性编程。
4. 执行时机：选择在LateUpdate中处理注册/注销和执行，可以确保本帧内所有对象的OnEnable/OnDisable调用都已经完成，状态是最新的。

4. 实操过程与核心环节实现

4.1 步骤一：定义你的管理接口与抽象基类

首先，根据你的具体需求定义接口。除了基本的更新，可能还需要固定更新、延迟更新等。

// IManagedBehaviour.cs public interface IManagedBehaviour { /// <summary> /// 每帧调用，等同于MonoBehaviour.Update /// </summary> void ManagedUpdate(); /// <summary> /// 固定时间步长调用，等同于MonoBehaviour.FixedUpdate /// </summary> void ManagedFixedUpdate(); /// <summary> /// 在ManagedUpdate之后调用，等同于MonoBehaviour.LateUpdate /// </summary> void ManagedLateUpdate(); /// <summary> /// 脚本实例的唯一标识，通常返回this.GetInstanceID() /// </summary> int InstanceID { get; } /// <summary> /// 更新优先级，用于排序执行顺序 /// </summary> int UpdatePriority { get; } } // 提供一个可选的抽象基类，简化实现 public abstract class ManagedBehaviourBase : MonoBehaviour, IManagedBehaviour { public int InstanceID => this.GetInstanceID(); public virtual int UpdatePriority => 0; public virtual void ManagedUpdate() { } public virtual void ManagedFixedUpdate() { } public virtual void ManagedLateUpdate() { } protected virtual void OnEnable() { BehaviourManager.Instance?.ScheduleRegister(this); } protected virtual void OnDisable() { BehaviourManager.Instance?.ScheduleUnregister(this); } }

使用抽象基类ManagedBehaviourBase，你的业务脚本只需要继承它，并重写需要的方法即可，无需手动处理注册逻辑，大大减少了样板代码和出错几率。

public class PlayerController : ManagedBehaviourBase { public override int UpdatePriority => 10; // 玩家控制优先级较高 public override void ManagedUpdate() { // 你的每帧逻辑，如输入处理 float moveX = Input.GetAxis("Horizontal"); // ... 移动逻辑 } public override void ManagedFixedUpdate() { // 你的物理逻辑 // _rigidbody.AddForce(...); } }

4.2 步骤二：实现支持优先级排序的管理器

上面的基础管理器是按注册顺序执行的。对于复杂系统，我们往往需要控制执行顺序。修改管理器，使其支持按UpdatePriority排序。

我们需要修改BehaviourManager的内部列表管理逻辑，在将脚本从缓冲列表添加到活跃列表时进行排序，或者维护一个已排序的列表。为了性能，我们可以在每次添加后标记需要重新排序，然后在执行前进行排序。

// 在BehaviourManager类内部增加 private bool _needSort = false; private void ProcessRegistrations() { lock (_lock) { // ... 处理 _behavioursToRemove ... if (_behavioursToAdd.Count > 0) { foreach (var behaviour in _behavioursToAdd) { if (behaviour == null || _behaviourMap.ContainsKey(behaviour.InstanceID)) continue; _activeBehaviours.Add(behaviour); _behaviourMap.Add(behaviour.InstanceID, behaviour); } _behavioursToAdd.Clear(); _needSort = true; // 标记需要排序 } } // 如果需要，对活跃列表进行排序 if (_needSort) { _activeBehaviours.Sort((a, b) => a.UpdatePriority.CompareTo(b.UpdatePriority)); _needSort = false; } } // 在LateUpdate中，先调用ProcessRegistrations，再遍历执行 private void LateUpdate() { ProcessRegistrations(); // ... 遍历执行逻辑 ... }

4.3 步骤三：处理场景加载与对象池

当使用场景加载（SceneManager.LoadScene）或对象池时，对象的激活/失活生命周期会更加复杂。

• 场景加载：新场景加载时，旧场景的对象会被销毁。如果你的管理器是DontDestroyOnLoad的，那么它持有的对旧场景对象的引用就会变成“僵尸引用”。必须在场景加载前后进行清理。
• 对象池：对象池中的对象会被频繁地SetActive(true/false)。这会导致OnEnable和OnDisable被频繁调用。我们的双缓冲机制能很好地处理这种高频调用，但要注意，从对象池取出的对象可能携带上一轮的状态，确保你的脚本在OnEnable中进行了正确的初始化。

为管理器添加场景加载监听：

using UnityEngine.SceneManagement; public class BehaviourManager : MonoBehaviour { // ... 其他代码 ... private void Awake() { if (_instance == null) { _instance = this; DontDestroyOnLoad(gameObject); SceneManager.sceneLoaded += OnSceneLoaded; } else if (_instance != this) { Destroy(gameObject); // 确保单例 } } private void OnSceneLoaded(Scene scene, LoadSceneMode mode) { // 场景加载后，清除所有可能来自旧场景的引用 // 因为旧场景的对象已被销毁，其引用无效 lock (_lock) { // 快速清理：直接清空列表和字典 // 更精细的做法是遍历并检查每个对象是否为null，但清空在场景切换时通常是安全的 _activeBehaviours.Clear(); _behaviourMap.Clear(); _behavioursToAdd.Clear(); _behavioursToRemove.Clear(); _needSort = false; } Debug.Log($"BehaviourManager cleared for scene: {scene.name}"); } private void OnDestroy() { if (_instance == this) { _instance = null; SceneManager.sceneLoaded -= OnSceneLoaded; // 记得取消订阅 } } }

5. 常见问题与排查技巧实录

即使有了稳健的架构，在实际开发中还是会遇到各种问题。下面是我总结的一些常见“坑”及其解决方法。

5.1 问题一：注册了但从未被调用（脚本的ManagedUpdate不执行）

可能原因及排查：

1. 管理器未运行：检查BehaviourManager的实例是否在场景中唯一且处于激活状态。可以在Awake或Start里加一句Debug.Log。
2. 脚本的OnEnable未触发：确认脚本所在的GameObject是否激活，脚本组件自身的勾选框是否被勾选。有时在编辑器运行时动态添加脚本，需要手动调用一次OnEnable的逻辑。
3. 优先级被误设：如果你实现了优先级排序，检查是否因为优先级设置错误（比如设了一个非常大的值），导致脚本被排序到很后面，而你又提前退出了遍历（比如设置了最大执行数量）。
4. 缓冲列表未同步：注册请求（ScheduleRegister）发出了，但管理器当前帧的LateUpdate尚未执行。这意味着脚本在本帧不会被更新。这是设计使然，通常下一帧就会正常。如果你的逻辑要求脚本在激活的同一帧就必须被更新，可以考虑在ScheduleRegister后立即手动触发一次管理器的更新循环（但这会破坏帧一致性，慎用）。

5.2 问题二：空引用异常（MissingReferenceException）

这是最令人头疼的问题，通常发生在对象已被销毁，但管理器列表中还保留着对其的引用。

我们的防御性编程已经很大程度上避免了它（通过缓冲列表、字典检查和遍历时的null检查）。但如果仍然出现，请检查：

1. 销毁路径是否统一：是否有些地方直接调用了Destroy(gameObject)，而有些地方是先SetActive(false)再延迟销毁？确保对象销毁前，OnDisable一定被调用，从而触发ScheduleUnregister。
2. 异步操作：如果在协程或异步回调中销毁对象，要确保这些操作在主线程执行，并且销毁前状态是可控的。
3. 使用GameObject.ReferenceEquals进行安全检查：在极少数情况下，Unity的==运算符对于被销毁的对象可能判断不准。可以使用if (behaviour as UnityEngine.Object == null)或if (System.Object.ReferenceEquals(behaviour, null))进行更严格的检查。

5.3 问题三：性能开销过大

当管理的脚本数量成千上万时，每帧遍历所有脚本并调用虚方法可能会成为性能瓶颈。

优化策略：

1. 分帧/分桶更新：不要在同一帧更新所有脚本。可以将脚本分成多个桶（Bucket），每帧只更新一个桶。这会导致每个脚本的更新频率降低，但能极大平滑CPU占用，适用于对实时性要求不高的后台逻辑（如AI感知更新、环境音效更新）。

   // 在管理器中 private int _currentBucketIndex = 0; private List<IManagedBehaviour>[] _buckets = new List<IManagedBehaviour>[5]; // 假设5个桶 // 每帧只更新一个桶 _currentBucketIndex = (_currentBucketIndex + 1) % _buckets.Length; var currentBucket = _buckets[_currentBucketIndex]; foreach(var behaviour in currentBucket) { ... }

2. 使用值类型和Burst Compiler：如果更新逻辑是纯数学计算，可以考虑使用Unity的ECS架构和Burst Compiler，但这涉及更大的架构改动。
3. 减少虚方法调用：虚方法调用有一定开销。如果性能极其敏感，可以考虑使用委托列表（Action），但会失去接口带来的清晰结构。需要权衡。
4. 按需更新：为IManagedBehaviour接口增加一个bool NeedsUpdate { get; }属性。管理器在遍历时先检查这个属性，如果为false则跳过。脚本可以在内部状态改变时设置这个属性。

5.4 问题四：与其他系统（如Unity事件系统）的冲突

你的自定义管理器可能会和Unity内置的UnityEvent或第三方的事件系统产生混淆。例如，一个UI按钮的onClick事件里激活了一个物体，这个物体的脚本会立即注册到你的管理器，并可能在当前帧就被更新。如果更新逻辑依赖于该UI事件的后续处理完成，就可能出现竞态条件。

解决思路：明确你的管理器更新的阶段。在LateUpdate中执行已经是比较靠后的阶段。如果还有冲突，可以考虑提供不同的更新通道，例如ManagedPreUpdate（在Update前）、ManagedPostUpdate（在Update后）、ManagedPreLateUpdate（在LateUpdate前）等，让脚本根据依赖关系选择注册到不同的通道。

6. 扩展与高级应用场景

基础的管理器搭建好后，我们可以根据项目需求进行扩展，使其更加强大和灵活。

6.1 场景一：实现一个全局的“定时任务调度器”

利用这个框架，可以轻松实现一个定时器。创建一个TimerBehaviour，它继承自ManagedBehaviourBase，在ManagedUpdate中累计时间，当达到指定间隔时，触发一个回调。

public class TimerBehaviour : ManagedBehaviourBase { private float _interval; private float _accumulator; private System.Action _onElapsed; private bool _isLooping; public void Setup(float interval, System.Action callback, bool loop = false) { _interval = interval; _onElapsed = callback; _isLooping = loop; _accumulator = 0f; enabled = true; // 确保自己处于激活状态以接收更新 } public override void ManagedUpdate() { _accumulator += Time.deltaTime; if (_accumulator >= _interval) { _onElapsed?.Invoke(); if (_isLooping) { _accumulator -= _interval; // 或 = 0f; } else { // 一次性定时器，触发后自我注销 enabled = false; // 这会触发OnDisable，从而从管理器移除 // 或者直接 Destroy(this.gameObject); } } } } // 使用示例 var timer = new GameObject("Timer").AddComponent<TimerBehaviour>(); timer.Setup(2.0f, () => Debug.Log("2秒到了！"));

管理器会自动管理这个TimerBehaviour的更新，无需你手动创建GameObject并挂载MonoBehaviour来驱动它。

6.2 场景二：构建一个非MonoBehaviour的“纯C#类”更新系统

有时我们有一些纯C#类（不继承MonoBehaviour）也需要每帧更新。我们可以让管理器支持任何实现了IManagedBehaviour接口的类，而不仅仅是MonoBehaviour。

public class PureCSharpUpdater : IManagedBehaviour { private int _id; public int InstanceID => _id; public int UpdatePriority => 0; private System.Action _updateAction; public PureCSharpUpdater(System.Action updateAction) { _id = GetHashCode(); // 或者用一个静态计数器生成唯一ID _updateAction = updateAction; // 主动向管理器注册自己 BehaviourManager.Instance?.ScheduleRegister(this); } public void Start() { // 模拟MonoBehaviour.Start，注册后可能需要一帧才开始 } public void Stop() { // 主动注销 BehaviourManager.Instance?.ScheduleUnregister(this); } public void ManagedUpdate() { _updateAction?.Invoke(); } // 实现其他接口方法... } // 使用 var myUpdater = new PureCSharpUpdater(() => { // 你的纯C#逻辑 CalculatePathfinding(); }); // 当不需要时 myUpdater.Stop();

这样，我们就将Unity的帧更新能力扩展到了普通的C#类，极大地增加了代码组织的灵活性。

6.3 场景三：与Unity的ScriptableObject结合，实现数据驱动的行为

ScriptableObject是存储数据和逻辑的利器。我们可以创建一种ScriptableBehaviour，其逻辑写在ScriptableObject中，但由管理器驱动更新。

// 定义一个ScriptableObject接口 public interface IScriptableManagedBehaviour { void ManagedUpdate(GameObject context); int UpdatePriority { get; } } // 管理器持有ScriptableObject的引用列表 public class BehaviourManager : MonoBehaviour { private List<IScriptableManagedBehaviour> _scriptableBehaviours = new List<IScriptableManagedBehaviour>(); // ... 类似的注册、注销、双缓冲逻辑 ... public void RegisterScriptableBehaviour(IScriptableManagedBehaviour behaviour, GameObject context) { // 需要将context（关联的游戏对象）也存储起来，以便更新时传入 } } // 创建一个具体的ScriptableObject [CreateAssetMenu(fileName = "RotateBehaviour", menuName = "Behaviours/Rotate")] public class RotateBehaviour : ScriptableObject, IScriptableManagedBehaviour { public float speed = 90f; public int UpdatePriority => 0; public void ManagedUpdate(GameObject context) { if (context != null) { context.transform.Rotate(Vector3.up, speed * Time.deltaTime); } } }

然后在某个MonoBehaviour中，将RotateBehaviour这个Asset注册到管理器，并传入自己所在的GameObject作为上下文。这样，旋转逻辑就完全和数据（Asset）绑定，可以在多个物体间共享和通过AssetBundle动态加载，实现了高度解耦和数据驱动。

整个系统从最初简单的列表添加删除，演变成了一个功能丰富、健壮可靠的行为管理框架。它解决了对象生命周期管理中的核心痛点，并提供了良好的扩展点，能够适应中小型Unity项目的多种复杂需求。记住，好的框架不是一开始就设计得大而全，而是像这样从一个具体问题出发，逐步迭代和完善出来的。希望这个详细的拆解能帮助你构建出更优雅、更稳定的Unity项目代码结构。