.NET依赖注入：使用静态服务描述符能否避免重复注册的性能问题？

在使用多个嵌套包注册DI服务时，部分服务不可避免会被多次添加到IServiceCollection中。于是我尝试通过静态集合定义DI服务，再用IServiceCollection的AddTransient()、AddSingleton()等方法注册。想请教两个问题：

1. 这种静态集合+TryAdd()的做法是否有效？
2. 重复添加等效服务是否会造成危害？

示例代码 #

public static class DIRegistrations
{
    private static readonly IEnumerable<ServiceDescriptor> FrequentlyAddedServices 
        = new ServiceCollection()
        .AddTransient<IFrequentlyAddedService1, FrequentlyAddedService1>()
        .AddTransient<IFrequentlyAddedService2, FrequentlyAddedService2>();
    
    
    public static IServiceCollection UseFrequentlyAddedServices(this IServiceCollection serviceCollection)
    {
        return serviceCollection.TryAdd(FrequentlyAddedServices);
    }
}

有一种变体是按引用检查现有实例（Microsoft的TryAdd()方法默认会比较服务类型/接口），如果不这么做，AddTransient()这类调用会被多次执行。

这种做法是否有用？ #

完全有效。通过静态集合预定义常用服务，再用扩展方法封装TryAdd()逻辑，能统一控制服务注册的入口，完美解决嵌套包重复注册相同服务的问题。

这种方式的核心优势：

• 集中管理高频注册的服务，避免重复代码分散在各个包中；
• 借助TryAdd()的特性，确保同一服务类型只会被注册一次，无论调用多少次UseFrequentlyAddedServices()都不会重复添加。

重复添加等效服务是否会造成危害？ #

分场景讨论：

• 瞬态（Transient）服务：重复注册相同实现不会导致内存泄漏，但会增加容器初始化的冗余操作。如果多次注册的是不同实现，解析服务时会返回最后一次注册的实例，可能引发逻辑不一致的问题。
• 单例（Singleton）服务：若重复注册相同实现，容器只会保留第一个注册的实例，后续注册会被忽略；但如果注册了不同实现，解析时会返回最后一个注册的实例，极易引发难以排查的逻辑混乱。
• 作用域（Scoped）服务：类似瞬态，重复注册会导致解析时返回最后一次注册的实现，增加调试难度，同时带来不必要的容器配置开销。

总的来说，重复注册等效服务（相同服务类型+相同实现）不会直接导致程序崩溃，但会增加冗余操作，更严重的是可能埋下“解析行为不一致”的隐患，提升维护成本。

关于TryAdd()的补充说明 #

• Microsoft的TryAdd()系列方法（包括TryAddTransient()、TryAddSingleton()以及示例中用的TryAdd(IEnumerable<ServiceDescriptor>)）核心逻辑是：仅当服务类型尚未注册时才执行添加操作。
• 这里的“已注册”判断依据是服务类型（比如IFrequentlyAddedService1），而非实现类型或实例引用。只要该服务类型已有任何注册记录，TryAdd()就会跳过。
• 如果需要更严格的检查（比如确保相同实现类型不重复注册），可以自定义逻辑：遍历现有ServiceDescriptor，同时对比服务类型和实现类型，只有两者都未匹配时才添加。

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