ConfigureServices中解析ISettingsService供AddSqlServer使用方案

首先明确：不建议在ConfigureServices方法执行过程中主动调用BuildServiceProvider()解析服务，你看到的Visual Studio警告，正是因为这种写法会创建独立于正式运行容器的冗余服务提供器，导致单例服务重复生成、资源泄漏、配置状态不一致等问题。

你之前看到的单例/瞬时注册方案核心逻辑是将服务解析逻辑推迟到DI容器正式构建完成后再执行，这个逻辑可以直接通过EF Core原生提供的AddSqlServer/AddDbContext重载实现，完全不会触发警告：

• 先将你的ISettingsService及实现正常注册到服务集合
• 使用带IServiceProvider参数的AddSqlServer重载，在委托中从框架传入的正式容器解析服务、获取连接字符串

示例代码：

// 第一步：注册自定义配置服务
services.AddSingleton<ISettingsService, SettingsService>();

// 第二步：注册DbContext，从框架提供的容器中解析配置
services.AddSqlServer<MyDbContext>((serviceProvider, dbContextOptions) =>
{
    // 这里的serviceProvider是应用正式运行用的根容器，不会产生冗余副本
    var settingsService = serviceProvider.GetRequiredService<ISettingsService>();
    var connStr = settingsService.GetDatabaseConnectionString();
    dbContextOptions.UseSqlServer(connStr);
});

这个写法是EF Core官方推荐的标准用法，没有任何副作用，完全规避手动构建服务提供器的问题。

如果你的SettingsService没有其他需要从DI注入的依赖，也可以选择在ConfigureServices中直接手动实例化服务，不需要走DI解析流程：

// 直接手动实例化配置服务
var settingsService = new SettingsService();
var connStr = settingsService.GetDatabaseConnectionString();

// 直接用拿到的连接字符串注册DbContext
services.AddSqlServer<MyDbContext>(connStr);

// 将手动实例化的对象注册到容器，供后续其他组件注入使用
services.AddSingleton<ISettingsService>(settingsService);

这个方案逻辑简单直观，零额外开销，适合配置服务依赖较少的场景。

不要通过设置BuildServiceProvider(true)、禁用代码分析警告的方式强行绕开提示，这种方式没有解决「冗余服务容器」的本质问题，后续出现单例状态异常、资源无法释放的问题时很难排查。

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