如何确保用户注册无法覆盖我的类库默认服务注册？

针对你需要让类库核心服务不被用户代码替换的需求，以下几种通用方案可以实现：

1. 封装私有内部服务容器，隔离核心依赖 #

不要将核心服务直接注册到用户提供的IServiceCollection，而是在类库内部维护一个独立的私有服务容器，核心服务仅在该容器中注册并实例化。对外暴露的服务接口通过代理类实现，代理内部调用私有容器中的核心服务实例。

示例代码：

// 类库内部私有容器
internal static class MyLibraryInternalContainer
{
    private static readonly ServiceProvider _provider;

    static MyLibraryInternalContainer()
    {
        var services = new ServiceCollection();
        // 注册类库核心服务，完全由类库控制
        services.AddSingleton<ICoreService, CoreServiceImpl>();
        _provider = services.BuildServiceProvider();
    }

    public static T GetRequiredService<T>() where T : notnull
    {
        return _provider.GetRequiredService<T>();
    }
}

// 对外暴露的代理类，用户只能拿到这个代理
public class CoreServiceProxy : ICoreService
{
    public void DoWork()
    {
        MyLibraryInternalContainer.GetRequiredService<ICoreService>().DoWork();
    }
}

// 类库的注册方法
public static IServiceCollection AddMyLibrary(this IServiceCollection services)
{
    // 对外只注册代理类，核心服务完全隔离
    services.AddSingleton<ICoreService, CoreServiceProxy>();
    return services;
}

优点：核心服务完全不受用户DI容器影响，用户无法替换；缺点：增加类库复杂度，核心服务无法使用用户容器中的其他依赖（若有需求）。

2. 注册时验证+拦截后续替换操作 #

在类库的AddMyLibrary方法中，先校验核心服务是否已被注册，若已注册直接抛出异常；然后通过自定义扩展拦截用户后续对核心服务的替换操作。

示例代码：

// 自定义标记，用于标识类库核心服务
internal class CoreServiceMarkerAttribute : Attribute { }

// 扩展方法，注册核心服务并标记
public static IServiceCollection AddStrictSingleton<TService, TImplementation>(this IServiceCollection services)
    where TService : class
    where TImplementation : class, TService
{
    // 检查是否已注册，若已注册则报错
    if (services.Any(d => d.ServiceType == typeof(TService)))
    {
        throw new InvalidOperationException($"核心服务 {typeof(TService).Name} 已被注册，无法替换");
    }

    // 注册服务并添加标记
    var descriptor = ServiceDescriptor.Singleton<TService, TImplementation>();
    var property = typeof(ServiceDescriptor).GetProperty("ImplementationType");
    if (property != null) property.SetValue(descriptor, typeof(TImplementation).GetCustomAttribute<CoreServiceMarkerAttribute>() != null ? descriptor.ImplementationType : descriptor.ImplementationType);
    services.Add(descriptor);

    return services;
}

// 拦截用户的替换操作
public static new IServiceCollection Add(this IServiceCollection services, ServiceDescriptor descriptor)
{
    // 如果是核心服务且已存在，阻止添加
    if (descriptor.ImplementationType?.GetCustomAttribute<CoreServiceMarkerAttribute>() != null &&
        services.Any(d => d.ServiceType == descriptor.ServiceType))
    {
        throw new InvalidOperationException($"无法替换类库核心服务 {descriptor.ServiceType.Name}");
    }

    // 调用原始Add方法
    return ((IServiceCollection)services).Add(descriptor);
}

// 类库注册方法
public static IServiceCollection AddMyLibrary(this IServiceCollection services)
{
    services.AddStrictSingleton<ICoreService, CoreServiceImpl>();
    return services;
}

优点：核心服务仍在用户容器中，可复用用户容器的部分能力；缺点：需要处理容器扩展的兼容性，部分第三方DI容器可能不支持拦截逻辑。

3. 核心服务内部实例化，脱离DI容器控制 #

对于绝对不允许替换的核心服务，直接在类库内部通过静态单例或静态构造函数创建实例，对外提供的服务直接使用该实例，不依赖DI容器注入。

示例代码：

public interface ICoreService
{
    void DoWork();
}

internal class CoreServiceImpl : ICoreService
{
    public void DoWork()
    {
        // 核心逻辑实现
    }
}

// 对外暴露的静态访问入口
public static class MyLibraryCoreServices
{
    public static readonly ICoreService CoreService = new CoreServiceImpl();
}

// 类库的其他组件直接使用内部实例
public class MyLibraryClient
{
    public void Execute()
    {
        MyLibraryCoreServices.CoreService.DoWork();
    }
}

优点：实现最简单，完全杜绝用户替换的可能；缺点：核心服务无法依赖注入其他组件，灵活性差，仅适用于无外部依赖的核心逻辑。

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