为何IServiceCollection无按服务与实现类型双过滤的TryAdd方法？

问题1：官方DI库是否存在同类实现 #

微软官方的Microsoft.Extensions.DependencyInjection已经提供了完全匹配你需求的方法：TryAddEnumerable，这个方法就是专门为「同一服务类型注册多个实现、按服务+实现组合去重」的场景设计的，你之前没找到是因为它不在常见的TryAddScoped/TryAddSingleton这类通用扩展方法里，而是属于ServiceCollectionDescriptorExtensions下的枚举注册专用方法。

它的去重规则和你的需求完全一致：只有当服务集合中已经存在相同服务类型、相同实现类型、相同生命周期的服务描述符时，才会跳过注册，不会像TryAddScoped那样只要服务类型存在就直接拦截所有后续注册。

用官方方法实现你的需求示例：

// 注册两个IS3EventHandler实现，重复调用也不会重复注册
services.TryAddEnumerable(ServiceDescriptor.Scoped<IS3EventHandler, TxtFileHandler>());
services.TryAddEnumerable(ServiceDescriptor.Scoped<IS3EventHandler, CsvHandler>());

// 解析时可正常拿到两个实现的集合
var handlers = serviceScope.ServiceProvider.GetServices<IS3EventHandler>();

问题2：自定义扩展方法的逻辑问题 #

你写的实现能覆盖最基础的泛型类型注册场景，但存在几个明显的边界漏洞：

• 仅支持通过ImplementationType直接指定实现类型的注册场景，没有覆盖「通过工厂方法注册（ImplementationFactory）」「直接注册实例（ImplementationInstance）」的情况。如果之前已经用services.AddScoped<IS3EventHandler>(sp => new TxtFileHandler())这种工厂形式注册过相同实现，你的判断逻辑里ImplementationType为null，会误判为未注册，导致重复注入。
• 没有做生命周期匹配校验：如果之前已经注册过同服务+同实现的Singleton生命周期服务，你调用Scoped版本的扩展方法时会直接跳过，不会按预期注册Scoped生命周期的实现，容易引出生命周期不匹配的隐性bug。
• 不支持开放泛型服务的注册去重，对通用扩展方法来说场景覆盖不全。

如果觉得每次写ServiceDescriptor.Scoped<,>()过于繁琐，你完全可以基于官方TryAddEnumerable封装简化版扩展，不需要自己从头写判断逻辑，避免遗漏边界：

public static class IServiceCollectionExtensions
{
    public static IServiceCollection TryAddScopedByService<TService, TImplementation>(this IServiceCollection services) 
        where TService : class 
        where TImplementation : class, TService
    {
        services.TryAddEnumerable(ServiceDescriptor.Scoped<TService, TImplementation>());
        return services;
    }

    public static IServiceCollection TryAddSingletonByService<TService, TImplementation>(this IServiceCollection services) 
        where TService : class 
        where TImplementation : class, TService
    {
        services.TryAddEnumerable(ServiceDescriptor.Singleton<TService, TImplementation>());
        return services;
    }
}

问题3：这种注册写法是否属于反模式 #

这种写法不是反模式，反而是很多场景下的标准实践。
在事件处理器、策略模式、管道过滤器、插件扩展这类需要同一接口多实现的场景中，本来就需要支持注册多个同接口实现，同时避免相同实现重复注册导致的逻辑重复执行（比如同一个S3事件被同一个处理器处理两次），这类需求非常普遍，不存在设计层面的问题。

唯一需要注意的是尽量复用官方提供的TryAddEnumerable能力，不要自己重复实现去重逻辑，避免漏处理边界场景引入bug。

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