多个服务实例共用同一IOptions模型的最优注册方案咨询

你期望的AddSingletonWithSetting风格的注册逻辑可以通过自定义IServiceCollection扩展方法实现，这是.NET依赖注入生态下的常规通用方案，完全符合官方设计规范，同时不需要修改你现有的Builder代码和配置结构。

方案1：自定义通用扩展方法（推荐适配你的需求） #

首先定义通用扩展类：

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Options;
using Microsoft.Extensions.Configuration;

public static class ServiceCollectionExtensions
{
    /// <summary>
    /// 注册单例服务，同时绑定专属的配置实例到IOptions
    /// </summary>
    public static IServiceCollection AddSingletonWithOptions<TService, TOptions>(
        this IServiceCollection services, 
        IConfigurationSection configSection) 
        where TService : class
        where TOptions : class
    {
        // 从配置节绑定参数
        var options = configSection.Get<TOptions>();
        var optionsWrapper = Options.Create(options);
        // 自动解析服务的其他构造依赖，仅手动传入专属的IOptions实例
        services.AddSingleton<TService>(serviceProvider => 
            ActivatorUtilities.CreateInstance<TService>(serviceProvider, optionsWrapper));
        return services;
    }

    /// <summary>
    /// 重载：支持手动委托配置参数
    /// </summary>
    public static IServiceCollection AddSingletonWithOptions<TService, TOptions>(
        this IServiceCollection services, 
        Action<TOptions> configure) 
        where TService : class
        where TOptions : class, new()
    {
        var options = new TOptions();
        configure(options);
        var optionsWrapper = Options.Create(options);
        services.AddSingleton<TService>(serviceProvider => 
            ActivatorUtilities.CreateInstance<TService>(serviceProvider, optionsWrapper));
        return services;
    }
}

使用方式和你预期的语法完全一致：

// 直接绑定配置节，最简写法
services.AddSingletonWithOptions<SearchBrandBuilder, IndexBuilderSettings>(
    Configuration.GetSection("SearchBrandConfig"));
services.AddSingletonWithOptions<SearchUnitBuilder, IndexBuilderSettings>(
    Configuration.GetSection("SearchUnitConfig"));

// 也支持手动配置参数
services.AddSingletonWithOptions<SearchUnitBuilder, IndexBuilderSettings>(settings => 
{
    settings.IndexName = "custom-units";
    settings.AdminApiKey = "xxx";
});

这个方案比你当前手动new实例的方案扩展性更强：如果后续Builder的构造函数新增其他需要从DI容器注入的依赖（比如ILogger、其他公共服务），不需要修改注册代码，ActivatorUtilities会自动从容器中解析对应参数。

方案2：强类型专属配置类（适合后续有差异化配置需求的场景） #

如果你不想自己维护扩展方法，也可以通过继承公共配置模型的方式，利用IOptions的泛型隔离特性避免配置覆盖：

1. 为每个Builder定义专属的空配置类，继承IndexBuilderSettings

public class SearchBrandBuilderSettings : IndexBuilderSettings {}
public class SearchUnitBuilderSettings : IndexBuilderSettings {}

2. 使用原生Configure方法注册，不同泛型参数的IOptions是互相隔离的单例

services.AddSingleton<SearchBrandBuilder>()
    .Configure<SearchBrandBuilderSettings>(Configuration.GetSection("SearchBrandConfig"));

services.AddSingleton<SearchUnitBuilder>()
    .Configure<SearchUnitBuilderSettings>(Configuration.GetSection("SearchUnitConfig"));

3. 修改对应Builder的构造函数注入对应专属配置即可

public class SearchBrandBuilder : SearchIndexBuilder<SearchBrandModel>
{
    public SearchBrandBuilder(IOptions<SearchBrandBuilderSettings> opts);
}

这个方案的优势是后续如果不同Builder需要新增独有的配置项，不需要修改公共的IndexBuilderSettings，对业务迭代的适配性更强。

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