在ConfigureServices方法中访问DBContext实现服务配置的方案咨询

手动调用services.BuildServiceProvider()会生成一个独立于应用最终运行时容器的服务提供者副本，会导致单例服务被重复实例化、生命周期约定被破坏，还可能带来内存泄漏、重复初始化的额外开销，因此官方明确不建议这种写法。

针对你的场景，有两种适配不同需求的正确实现方案：

不需要依赖DI容器获取DbContext，手动构建临时的DbContext实例读取数据即可，完全不会影响后续DI容器的正常构建：

public void ConfigureServices(IServiceCollection services)
{
    // 先从配置文件读取数据库连接字符串
    var connString = Configuration.GetConnectionString("Default");
    // 手动构造DbContext配置
    var dbOpts = new DbContextOptionsBuilder<MyDbContext>()
        .UseSqlServer(connString)
        .Options;
    // 初始化临时DbContext，读取完成后立即释放
    using var tempDb = new MyDbContext(dbOpts);
    var serviceRegConfigs = tempDb.ServiceRegisterConfigs.ToList();

    // 用读取到的配置完成后续服务注册
    foreach (var config in serviceRegConfigs)
    {
        services.AddHttpClient(config.ServiceKey, client =>
        {
            client.BaseAddress = new Uri(config.ServiceUrl);
            client.Timeout = TimeSpan.FromSeconds(config.Timeout);
            // 其他自定义参数配置
        });
    }

    // 后续正常注册DbContext到DI容器即可，和上面的临时实例完全不冲突
    services.AddDbContext<MyDbContext>(opts => opts.UseSqlServer(connString));

    // 其他服务注册逻辑
}

这个方案的优势是逻辑简单直接，和正常的服务注册流程完全对齐，没有多余的性能损耗。

利用DI的工厂注册重载，把配置读取逻辑延迟到服务第一次被调用时执行，完全不需要在ConfigureServices阶段访问数据库：

// 注册自定义服务时用工厂重载，在工厂内部从DI容器获取DbContext读配置
services.AddSingleton<ICustomService>(serviceProvider =>
{
    var db = serviceProvider.GetRequiredService<MyDbContext>();
    var runConfig = db.ServiceConfigs.First(c => c.ServiceName == "CustomService");
    return new CustomService(runConfig.ServiceUrl, runConfig.ExtraParams);
});

// 如果是HttpClient也可以用相同逻辑
services.AddHttpClient("DynamicService", (sp, client) =>
{
    var db = sp.GetRequiredService<MyDbContext>();
    var config = db.ServiceConfigs.First(c => c.ServiceName == "DynamicService");
    client.BaseAddress = new Uri(config.ServiceUrl);
});

这种方案更符合DI的设计原则，还可以按需扩展配置缓存、定时刷新的逻辑，支持运行时动态更新服务配置。

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