实例化多个通用主机（IHost）实例是否可行？

我们团队有一套构建微服务应用及相关作业的框架，计划将Web应用用<IWebHost>、作业用<IHost>的模式统一改为全部使用<IHost>，但目前因依赖注入（DI）问题卡壳了。

之前用<WebHostBuilder>和Startup类时，我们可以先构建一个服务容器，用里面的服务获取配置值并绑定，再重新构建包含所有所需服务的容器。通过这种方式能提前绑定配置服务，从数据存储拿到配置并绑定到强类型<IOptions>，让其他服务能从DI系统获取绑定后的<IOptions>。

但<IHost>不支持这种“双重DI”机制，导致框架的作业部分只能临时拼凑方案传递配置（没法绑定到<IOptions>）。

我想找一种用<IHost>时，依然能注册服务、调用服务获取配置、绑定到<IOptions>供全应用使用的方法。目前想到在Main()方法里创建两个<IHost>实例，这个方案能正常运行，但想问问这么做会不会引发问题？

代码示例：

public static void Main(string[] args)
{
    var tempHost = Host.CreateDefaultBuilder(args)
        .ConfigureServices(services =>
        {
            services.AddTransient<IConfigService, ConfigService>();
        })
        .Build();

    var configModel = tempHost.Services.GetRequiredService<IConfigService>().GetConfigModel();
    IConfigurationRoot? configurationRoot = null;
    tempHost.Dispose();

    var host = Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((context, builder) =>
        {
            configurationRoot = builder.AddInMemoryCollection(GetSettings(configModel)).Build();
        })
        .ConfigureServices(services =>
        {
            services.AddHostedService<MyWorker>();
            services.AddTransient<IConfigService, ConfigService>();
            services.Configure<ConfigModel>(configurationRoot);
            services.AddTransient<IGoofballService, GoofballService>();
        })
        .Build();

    host.Run();
}

private static Dictionary<string, string> GetSettings(ConfigModel model)
{
    var dictionary = new Dictionary<string, string>();
    var typeName = nameof(ConfigModel);

    dictionary.Add($"{typeName}:{nameof(model.Id)}", model.Id.ToString());
    dictionary.Add($"{typeName}:{nameof(model.Stamp)}", model.Stamp.ToString(CultureInfo.InvariantCulture));

    return dictionary;
}

双<IHost>实例的潜在问题 #

• 资源泄漏风险：如果ConfigService依赖了数据库连接、网络客户端等需手动释放的资源，即便调用tempHost.Dispose()，也可能因资源未被正确释放（比如单例服务、Dispose逻辑不完整）导致泄漏。
• 配置不一致：临时Host和正式Host的初始配置可能存在差异（比如环境变量、命令行参数的解析逻辑），两次CreateDefaultBuilder的上下文不同，可能导致拿到的配置模型和正式运行环境不匹配。
• 代码冗余难维护：重复注册服务（比如两次添加IConfigService），后续服务依赖变化时需同时修改两处，容易出错。
• 启动性能损耗：创建Host实例涉及大量初始化工作（配置加载、DI容器构建），两次构建会增加启动时间，对需要快速启动的作业服务不友好。

更优雅的替代方案：在配置构建阶段获取配置 #

无需创建临时Host，直接利用ConfigureAppConfiguration的扩展能力，在配置构建流程中调用配置服务获取配置，再添加到主配置体系：

public static void Main(string[] args)
{
    Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((context, builder) =>
        {
            // 构建临时配置和服务提供者，用于获取ConfigService
            var tempConfig = builder.Build();
            var tempServices = new ServiceCollection()
                .AddTransient<IConfigService, ConfigService>()
                // 注入临时配置到ConfigService（如果需要）
                .AddSingleton<IConfiguration>(tempConfig)
                .BuildServiceProvider();

            try
            {
                var configService = tempServices.GetRequiredService<IConfigService>();
                var configModel = configService.GetConfigModel();
                // 将外部获取的配置添加到主配置体系
                builder.AddInMemoryCollection(GetSettings(configModel));
            }
            finally
            {
                // 释放临时服务提供者
                (tempServices as IDisposable)?.Dispose();
            }
        })
        .ConfigureServices(services =>
        {
            services.AddHostedService<MyWorker>();
            services.AddTransient<IConfigService, ConfigService>();
            // 绑定主配置中的ConfigModel节点到IOptions
            services.Configure<ConfigModel>(context => context.Configuration.GetSection(nameof(ConfigModel)));
            services.AddTransient<IGoofballService, GoofballService>();
        })
        .Build()
        .Run();
}

private static Dictionary<string, string> GetSettings(ConfigModel model)
{
    var dictionary = new Dictionary<string, string>();
    var typeName = nameof(ConfigModel);

    dictionary.Add($"{typeName}:{nameof(model.Id)}", model.Id.ToString());
    dictionary.Add($"{typeName}:{nameof(model.Stamp)}", model.Stamp.ToString(CultureInfo.InvariantCulture));

    return dictionary;
}

方案优势 #

• 规避双Host资源问题：仅创建临时服务提供者，范围更小，资源释放更易控制。
• 配置一致性：基于同一个初始配置构建临时服务，保证拿到的配置与正式环境初始配置一致。
• 代码简洁易维护：无需重复构建完整Host，逻辑集中在配置构建阶段，后续修改更方便。
• 启动性能更优：跳过Host初始化的额外步骤（如日志、主机生命周期管理），启动速度更快。

如果ConfigService依赖较少，甚至可以直接实例化，进一步简化代码：

// 若ConfigService可直接实例化，无需DI
var configService = new ConfigService(tempConfig);
var configModel = configService.GetConfigModel();

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