Unity为何不默认缓存组件？自制GetComponent缓存方案存问题吗？

我为Unity的GetComponent()编写了自定义封装，做成替代MonoBehaviour的基类，目的是让调用GetComponent()时无需顾虑性能问题。代码如下：

public abstract class MonoBase : MonoBehaviour
{
    private readonly Dictionary<Type, Component> _components = new();

    public new T GetComponent<T>() where T : Component
    {
        var type = typeof(T);
        
        if (!_components.ContainsKey(type))
        {
            var component = gameObject.GetComponent<T>();
            
            if (component != null)
                _components.Add(type, component);
            else
                _components.Add(type, gameObject.AddComponent<T>());
        }
        
        return (T)_components[type];
    }
}

但我有两个疑问：

1. 为什么Unity最初不实现这种组件缓存功能？
2. 这种看似简单的缓存手段是否存在潜在问题？

为什么Unity原生不默认实现组件缓存？ #

• 场景适配与灵活性优先：Unity的API设计需要覆盖所有开发场景，组件的动态增删是很常见的操作。如果默认缓存，当组件被手动销毁或移除后，缓存中的引用会变成无效的"僵尸对象"，此时调用GetComponent()返回的不是当前对象的真实状态，会引发难以排查的bug。原生GetComponent()每次实时查询，就是为了保证返回的是组件的最新状态。
• 避免不必要的内存开销：每个MonoBehaviour实例都维护一个Dictionary缓存，对于大量实例（比如成百上千的场景对象），额外的内存占用会累积。Unity不会给所有开发者强加这个成本——毕竟很多场景下GetComponent()的调用频率很低，或者开发者会根据自己的需求手动缓存特定组件。
• 语义一致性的考量：原生GetComponent()的核心语义是"获取当前GameObject上存在的指定类型组件"。如果默认缓存，当组件被移除后重新添加，缓存返回的还是旧引用，完全违背了原方法的语义，会破坏依赖原生行为的现有代码逻辑。

你的缓存实现存在哪些潜在问题？ #

• 动态组件变更导致引用失效：如果代码运行过程中，某个被缓存的组件被Destroy()或从对象上移除，缓存里的引用不会自动更新。下次调用GetComponent<T>()会返回已销毁的组件，触发NullReferenceException或异常行为。
• 自动添加组件的意外风险：你的代码中，当找不到对应组件时会自动调用AddComponent<T>()，这完全改变了原生GetComponent()的语义——原生方法找不到组件会返回null，而你的实现会直接修改对象结构。很多时候开发者调用GetComponent()只是为了检查组件是否存在，自动添加会导致意外的组件依赖，破坏对象的设计结构。
• 缓存未提供更新/清理机制：如果对象上的组件被替换（比如移除旧组件后添加新的同类型组件），缓存不会自动刷新，会一直返回旧的无效引用。
• 泛型类型的场景局限性：如果你的对象上存在多个同类型的子类组件，第一次调用GetComponent<T>()会获取到第一个匹配的组件并缓存，但后续添加的同类型组件无法通过这个方法获取到，这可能不符合某些场景的需求。

内容的提问来源于stack exchange，提问作者Nidere