在 ASP.NET Core 应用中，EF Core 与依赖注入容器的结合点集中在 DbContext 的注册和解析方式。如果只是按老习惯在仓储层里直接新建一个上下文，不仅无法享受配置自动装载的好处，还容易造成连接字符串分散、日志缺失和生命周期失控。EF Core 提供了一套基于服务容器的扩展方法，让数据库访问组件可以像普通服务一样被注入和管理。
日常开发里最常见的做法是使用 AddDbContext 泛型扩展，它会在容器中注册 DbContext 子类以及对应的 DbContextOptions。这个扩展默认采用 Scoped 生命周期，也就是说每个 HTTP 请求会拿到一个新的上下文实例，请求结束后由容器负责释放。这样能避免上下文长时间占用连接，也符合 Web 请求的工作单元模式。
一、AddDbContext 的基础注册方式
在 .NET 6 及之后的极简主机模型中，注册代码通常写在 Program.cs 文件里。先读取配置文件中的连接字符串，再选择数据库提供程序，例如 SQL Server 使用 UseSqlServer，PostgreSQL 使用 UseNpgsql。整个过程不需要手动解析 IConfiguration，服务容器会在后台完成依赖装配。
下面是一个基础示例。注册完成后，控制器、最小 API 或任意服务都可以通过构造函数直接注入 AppDbContext，无需额外的工厂方法。
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<AppDbContext>(options =>
options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));
var app = builder.Build();
app.MapGet("/products", async (AppDbContext db) =>
await db.Products.ToListAsync());
app.Run();
这里使用的 AddDbContext<AppDbContext> 是 EF Core 提供的扩展方法，位于 Microsoft.Extensions.DependencyInjection 命名空间。它不仅仅把上下文注册为服务，还会注册 DbContextOptions<AppDbContext>、数据库提供程序、日志记录器以及拦截器等内部依赖。如果以后想调整 SQL 日志输出或增加全局查询过滤器，只需要在同一个 options 回调里配置，修改起来非常集中。
还需要注意，AddDbContext 的生命周期固定为 Scoped，没有直接参数可以改成 Singleton 或 Transient。这是有意的设计，因为 DbContext 内部维护了变更跟踪器和数据库连接，单例复用会带来线程安全和数据陈旧问题。如果某个服务需要更短或更长的上下文生命周期，应该通过作用域工厂手动创建，而不是改变注册方式。
二、AddDbContextFactory 与 AddDbContextPool 的适用场景
对于 Blazor Server、桌面应用或后台任务等场景，一个请求作用域很难覆盖完整的操作周期，这时可以使用 AddDbContextFactory。它会在容器中注册 IDbContextFactory<AppDbContext>，由调用方决定何时创建和释放上下文。工厂本身可以注册为 Singleton，因为它不直接持有 DbContext 实例，只是提供创建新上下文的能力。
另一个容易混淆的方法是 AddDbContextPool。它启用 DbContext 池化，EF Core 会维护一组可复用的上下文实例，在高并发请求下减少对象创建和销毁的开销。池化上下文在释放时会被重置状态，因此不能依赖构造函数中的一次性初始化逻辑，也不建议存储跨请求的私有字段。
builder.Services.AddDbContextFactory<AppDbContext>(options =>
options.UseNpgsql(builder.Configuration.GetConnectionString("PostgresConnection")));
builder.Services.AddDbContextPool<AppDbContext>(options =>
options.UseSqlServer(builder.Configuration.GetConnectionString("SqlConnection")));
如果需要同时注册普通上下文和工厂，可以调用两个扩展方法，但要注意它们的配置来源各自独立，后续修改连接字符串或提供程序时必须同步调整。更推荐的做法是创建一个配置委托变量，复用同一份 Action<DbContextOptionsBuilder>，减少配置漂移。
池化在性能测试中能带来明显的吞吐量提升，尤其是请求处理时间较短、数据库操作频繁的服务。但如果应用中大量使用全局查询过滤器、租户过滤或动态查询，重置状态的成本可能抵消收益。此时可以先通过基准测试对比，再决定是否启用池化。
三、作用域陷阱：在单例服务中误用 DbContext
这是实际项目中最常见的问题之一：把一个 Scoped 的 AppDbContext 注入到 Singleton 服务中，编译阶段不会报错，运行时却可能抛出 Cannot consume scoped service from singleton 的异常。即使在 .NET Core 3.0 之前没有强制校验，也容易出现上下文已释放或并发访问同一个跟踪器的问题。
后台任务、消息队列消费者、定时器回调都可能在 singleton 生命周期中运行。要安全访问数据库，应该注入 IServiceScopeFactory，在方法执行时创建一个临时作用域，再从该作用域中解析 DbContext。
public class DataSyncService : BackgroundService
{
private readonly IServiceScopeFactory _scopeFactory;
public DataSyncService(IServiceScopeFactory scopeFactory)
{
_scopeFactory = scopeFactory;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
using var scope = _scopeFactory.CreateScope();
var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
var pendingOrders = await dbContext.Orders
.Where(o => o.Status == "Pending")
.ToListAsync(stoppingToken);
foreach (var order in pendingOrders)
{
// 执行同步逻辑
}
}
}
上面的代码中，作用域对象 scope 在 using 块结束后会被释放，同时释放从该作用域解析出来的 AppDbContext。这里不需要手动调用 Dispose，但必须把整个数据库操作放在 using 块内部完成，否则离开作用域后再访问上下文会触发 ObjectDisposedException。
还有一种变体是在单例服务中注入 IDbContextFactory<AppDbContext>，这也是更简洁的方案。因为工厂本身就是为这种独立创建场景设计的，调用 CreateDbContextAsync 或 CreateDbContext 即可获得短生命周期上下文，用完手动释放，不需要关心作用域管理。
四、多租户场景下的动态连接字符串配置
多租户架构中，每个租户可能连接不同的数据库，连接字符串往往需要在请求到达后才能确定。如果只在注册时写死一个连接字符串，就无法满足需求。EF Core 的 AddDbContext 有一个重载，允许在回调中访问 IServiceProvider，从而解析当前请求中的租户服务并动态构建选项。
不过这个重载有一个关键细节：options 构建的结果会被缓存，如果租户信息变化但解析出的连接字符串没有体现在缓存键里，可能出现串库或拿到错误配置。因此更稳妥的做法是使用 IDbContextFactory，在每次创建上下文时重新计算连接字符串。
builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<ITenantProvider, CurrentTenantProvider>();
builder.Services.AddDbContext<AppDbContext>((serviceProvider, options) =>
{
var tenantProvider = serviceProvider.GetRequiredService<ITenantProvider>();
var connectionString = tenantProvider.GetConnectionString();
options.UseSqlServer(connectionString);
});
这种注册方式适合请求作用域内租户解析稳定、且连接字符串变化不频繁的系统。租户服务 ITenantProvider 通常从 HttpContext 的请求头或用户声明中读取租户标识，再查询配置中心获取实际连接串。需要保证 ITenantProvider 也是 Scoped，否则在 singleton 中解析不到当前请求信息。
如果系统规模较大，建议把租户解析逻辑独立成中间件或过滤器，在进入控制器前完成身份与数据库映射。这样 DbContext 的创建过程保持稳定，租户切换只影响数据源，不干扰其他业务逻辑。
五、注册顺序与日志拦截器的配合
依赖注入的注册顺序通常不会影响 EF Core 本身的解析，但如果涉及拦截器、日志工厂或自定义服务替换，就有必要注意注册先后。例如注册了一个自定义 IInterceptor，然后通过 AddInterceptors 添加到 DbContext 选项，这个拦截器实例会从服务容器中解析，因此必须确保它在 DbContext 注册之前已经加入容器。
日志记录同样可以依赖注入。EF Core 默认会把 SQL 日志发送到 ILoggerFactory，在开发环境打开 LogLevel.Information 就能看到生成的 SQL 语句。通过 options.LogTo 可以自定义输出目标，也可以使用 EnableSensitiveDataLogging 输出参数值，但生产环境要谨慎，避免泄漏敏感信息。
builder.Services.AddSingleton<IInterceptor, CustomDbCommandInterceptor>();
builder.Services.AddDbContext<AppDbContext>((sp, options) =>
{
options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection"))
.AddInterceptors(sp.GetRequiredService<IInterceptor>())
.LogTo(Console.WriteLine, LogLevel.Information);
});
LogTo 中的 Console.WriteLine 是委托，不是依赖注入解析出来，只是将日志输出到控制台。如果希望集成到结构化日志系统，使用 ILoggerFactory 更合适，因为 EF Core 会自动把日志归类到 Microsoft.EntityFrameworkCore 类别下，方便按模块过滤。
总体来看，EF Core 在 ASP.NET Core 中的依赖注入并不复杂，核心是选对注册方法，并让 DbContext 的生命周期与业务操作边界保持一致。遇到作用域错误时，优先检查是否在 singleton 中直接使用了 scoped 服务，再根据场景决定引入工厂或作用域工厂。
EF Core依赖注入ASP.NET Core修改时间：2026-09-27 18:22:33