1. 这不是“配个依赖”那么简单EF框架Autofac注入到底在解决什么问题你看到“EF框架配置Autofac注入”这个标题第一反应可能是——又一个.NET老生常谈的依赖注入配置教程点开前心里已经预设了复制几段Startup.cs代码、注册几个ServiceCollection、再加个AddScoped就完事了。但如果你真这么干过大概率踩过坑EF的DbContext在多线程下报“ObjectDisposedException”仓储层调用时突然发现上下文已释放或者单元测试里Mock不生效、生命周期混乱得像一锅粥。这些不是配置写错了而是对EF DbContext本质生命周期和Autofac容器行为逻辑的双重误判。我带过好几个团队做.NET后端重构几乎每支队伍都在EFAutofac组合上卡过至少两周。问题从来不在“会不会写RegisterType()”而在于没想清楚为什么EF的DbContext必须是Scoped为什么不能直接注册为Singleton为什么在Web API里用InstancePerLifetimeScope在后台服务里却要换InstancePerDependency这些选择背后是数据库连接池管理、事务边界控制、内存泄漏风险、以及并发请求隔离等一整套底层机制在起作用。Autofac不是个万能胶水它是个精密的生命周期调度器EF DbContext也不是个普通类它是个带着连接、缓存、变更追踪状态的有状态对象。这篇文章面向三类人一是刚从ASP.NET Core默认DI切换过来、发现Autofac“不听话”的开发者二是正在做中大型系统架构设计、需要明确各层对象生命周期边界的架构师三是被线上偶发DbContext异常折磨得睡不着觉的运维/开发同学。我们不讲抽象理论不堆砌接口定义就从一次真实压测故障切入——某次订单服务在QPS破800时5%请求返回“无法访问已释放的对象”日志显示DbContext被提前Dispose。排查三天后发现问题出在Autofac注册时把仓储类设成了SingleInstance而仓储内部持有的DbContext却是Scoped导致多个请求共用同一个DbContext实例。这种细节文档不会写视频教程也常一笔带过。接下来的内容就是我把这十年踩过的坑、画过的生命周期图、验证过的配置组合全部摊开来讲清楚。2. 核心设计逻辑拆解为什么必须用AutofacEF默认DI不够用吗2.1 默认DI的“够用”边界在哪ASP.NET Core内置的Microsoft.Extensions.DependencyInjectionMS.DI确实能跑通EF基本场景AddDbContextPool注册DbContextAddScoped注册仓储Controller构造函数注入——看起来一切正常。但它的能力边界非常清晰仅支持三种生命周期Transient/Scoped/Singleton且不提供跨作用域的精细控制、条件注册、属性注入、模块化配置等企业级能力。举个具体例子你的系统有Web API层、后台任务队列如Hangfire、SignalR实时通知三个入口。它们都需要访问订单数据但需求完全不同Web API请求需保证每个HTTP请求独占一个DbContext支持事务回滚Hangfire后台任务需独立于HTTP上下文但又要保证单个任务内DbContext复用避免多次创建连接SignalR Hub需在长连接生命周期内复用DbContext而非每次消息都新建。MS.DI对此无解——它没有“按入口类型划分作用域”的能力。你无法告诉它“对Controller请求用HttpContext.RequestServices对Hangfire Job用JobServices”。而Autofac的InstancePerLifetimeScope配合自定义作用域标签Tag就能精准实现Web API用BeginLifetimeScope(web)Hangfire用BeginLifetimeScope(job)SignalR用BeginLifetimeScope(hub)再配合Where(x x.ServiceType typeof(DbContext))的条件注册三者互不干扰。提示这不是Autofac的炫技功能而是应对真实业务复杂度的刚需。某电商系统在接入物流异步回调时因回调服务与主站共享同一DI容器导致物流回调中DbContext被主站请求意外Dispose引发数据不一致。改用Autofac分作用域后问题根除。2.2 Autofac的核心优势不只是“更强大”而是“更可控”Autofac真正不可替代的价值在于它把容器行为完全暴露给你控制。我们对比关键能力能力维度MS.DI默认Autofac实际影响生命周期粒度仅3种固定模式支持InstancePerLifetimeScope、InstancePerMatchingLifetimeScope、Owned 等可为Hangfire Job、Quartz定时任务、gRPC Call单独建作用域避免DbContext污染注册方式静态方法链式调用模块化Module、XML配置、程序集扫描、Lambda表达式大型项目可按业务域拆Module如OrderModule、UserModule配置解耦新人易上手解析上下文仅通过IServiceProvider提供ILifetimeScope、IComponentContext支持嵌套作用域、子容器在事务拦截器中动态创建子作用域确保事务内所有操作共享同一DbContext事务外自动释放条件注册不支持Where()、When(), WhenAnyAncestorMatches()等丰富谓词只对继承自IRepository 的类型注册或仅当环境变量Production时启用缓存装饰器属性注入不支持需手动SetProperty原生支持PropertiesAutowired()对第三方库中无法修改构造函数的类如某些ORM扩展可通过属性注入Logger等依赖最关键的是Owned——这是Autofac独有的“托管实例”概念。当你注册builder.RegisterTypeOrderService().AsSelf().InstancePerLifetimeScope()再通过scope.ResolveOwnedOrderService()获取时Autofac会返回一个OwnedOrderService包装对象其内部包含Value实际实例和Dispose()方法。调用Dispose()会立即释放该实例及其依赖树包括DbContext。这在需要手动控制资源释放的场景如长周期批处理、文件导入导出中比等待作用域结束更安全可靠。注意很多人误以为“用了Autofac就一定比MS.DI强”其实不然。对于纯Web API小项目MS.DI更轻量、启动更快、调试更直观。Autofac的价值只在系统复杂度突破某个阈值后才显现——这个阈值通常是存在≥2种非HTTP请求入口、需细粒度事务控制、依赖关系超过50个、或团队需模块化协作开发。2.3 EF DbContext的生命周期真相为什么“Scoped”不是万能解药这是最常被误解的一环。网上90%的教程告诉你“DbContext必须注册为Scoped”然后贴出AddDbContextPool代码。但没人告诉你Scoped在Autofac和MS.DI中语义不同且EF DbContext的“Scoped”本质是“Per Request”而非“Per Scope”。EF Core官方文档明确指出DbContext设计为短生命周期、有状态对象。它内部维护数据库连接Connection更改追踪器ChangeTracker查询缓存Query Cache事务上下文Transaction这些状态决定了它绝不能跨请求共享。MS.DI的Scoped生命周期绑定到HTTP请求所以AddDbContextPool能安全复用DbContext实例连接池层面复用实例仍按请求隔离。但Autofac的InstancePerLifetimeScope默认不绑定HTTP上下文——如果你在Startup中这样注册builder.Register(c new AppDbContext(new DbContextOptionsBuilderAppDbContext().UseSqlServer(...).Options)) .AsSelf() .InstancePerLifetimeScope(); // ❌ 错误未绑定到HTTP请求那么每次BeginLifetimeScope()都会创建新DbContext而HTTP请求结束时Autofac并不知道该Dispose它因为没关联HTTP上下文导致连接泄漏。正确做法是让Autofac的Scope与ASP.NET Core的RequestScope对齐。这需要两步在Startup.ConfigureServices中将Autofac容器作为ServiceProviderFactory传入public IServiceProvider ConfigureServices(IServiceCollection services) { // 其他服务注册... var container new ContainerBuilder(); container.Populate(services); // 将MS.DI注册项导入Autofac // 此处注册你的自定义类型 return new AutofacServiceProvider(container.Build()); }在Configure中启用Autofac的RequestLifetimeHttpModule.NET Core 3.1或使用Autofac.Extensions.DependencyInjection包的UseAutofac()扩展确保每个HTTP请求自动创建并释放ILifetimeScope。只有完成这一步“InstancePerLifetimeScope”才真正等价于MS.DI的“Scoped”。否则你只是在Autofac里造了个假Scoped。3. 实操配置详解从零开始搭建稳定可靠的EFAutofac注入体系3.1 环境准备与依赖安装版本兼容性是第一道坎别跳过这一步。我见过太多团队因版本不匹配浪费数天EF Core 6.0 Autofac 6.0 .NET 6.0 组合看似合理但Autofac.Extensions.DependencyInjection包若用错版本Populate()方法会静默失败导致服务解析为空。当前2024年经实测稳定的组合是.NET SDK: 6.0 LTS 或 8.0推荐8.0性能提升显著EntityFrameworkCore: 8.0.0注意8.0移除了IDbContextFactoryT的默认实现需手动注册Autofac: 8.0.0核心容器Autofac.Extensions.DependencyInjection: 9.0.0桥接MS.DI与Autofac的关键包Autofac.Extras.DynamicProxy: 8.0.0如需AOP拦截如事务、日志安装命令以.NET 8.0为例dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 8.0.0 dotnet add package Autofac --version 8.0.0 dotnet add package Autofac.Extensions.DependencyInjection --version 9.0.0 dotnet add package Autofac.Extras.DynamicProxy --version 8.0.0提示不要用--prerelease参数安装预发布版。Autofac 8.x系列已稳定预发布版常含未修复的生命周期bug。某金融系统曾因使用Autofac 7.2.0-rc1导致后台任务中DbContext在作用域结束前被GC回收引发空引用异常。3.2 核心注册代码四层结构确保零歧义Autofac注册不是“把所有类扔进容器”而是分层构建依赖契约。我采用四层注册法已在5个中大型项目中验证其可维护性第一层基础设施注册Infrastructure注册EF DbContext、数据库连接字符串、基础工具类如ILogger、IConfiguration。// InfrastructureModule.cs public class InfrastructureModule : Module { protected override void Load(ContainerBuilder builder) { // 1. 注册DbContext关键绑定到HTTP请求作用域 builder.Register(c { var options new DbContextOptionsBuilderAppDbContext() .UseSqlServer( c.ResolveIConfiguration().GetConnectionString(DefaultConnection), opt opt.EnableRetryOnFailure()); // 启用连接重试 return new AppDbContext(options.Options); }) .AsSelf() .InstancePerLifetimeScope() // ✅ 此处Scoped已与HTTP请求对齐 .WithParameter(options, (c, p) c.ResolveDbContextOptionsAppDbContext()); // 2. 注册IDbContextFactoryEF Core 8.0必需 builder.Register(c new DbContextFactoryAppDbContext( c.ResolveDbContextOptionsAppDbContext())) .AsIDbContextFactoryAppDbContext() .InstancePerLifetimeScope(); // 3. 注册基础服务 builder.RegisterTypeLoggerAppDbContext().AsILoggerAppDbContext().InstancePerLifetimeScope(); builder.RegisterInstance(ConfigurationManager.Configuration).AsIConfiguration(); } }第二层领域服务注册Domain注册领域模型、仓储接口、领域服务。// DomainModule.cs public class DomainModule : Module { protected override void Load(ContainerBuilder builder) { // 仓储接口注册按约定扫描避免漏注册 builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly()) .Where(t t.IsClass t.Name.EndsWith(Repository)) .AsImplementedInterfaces() .InstancePerLifetimeScope(); // 领域服务显式注册明确依赖 builder.RegisterTypeOrderService() .AsIOrderService() .InstancePerLifetimeScope() .EnableInterfaceInterceptors() // 为AOP预留 .InterceptedBy(typeof(TransactionInterceptor)); // 事务拦截器 } }第三层应用服务注册Application注册应用层服务、DTO映射器、第三方SDK客户端。// ApplicationModule.cs public class ApplicationModule : Module { protected override void Load(ContainerBuilder builder) { // AutoMapper配置 builder.Register(c new MapperConfiguration(cfg { cfg.AddProfileOrderMappingProfile(); }).CreateMapper()) .AsIMapper() .SingleInstance(); // Mapper是无状态的可全局单例 // 第三方支付SDK客户端需设置超时、重试 builder.Register(c { var config c.ResolveIConfiguration(); return new AlipayClient( config[Alipay:AppId], config[Alipay:PrivateKey], config[Alipay:PublicKey]); }) .AsIAlipayClient() .InstancePerLifetimeScope(); } }第四层表现层注册Presentation注册Controller、API过滤器、中间件依赖。// PresentationModule.cs public class PresentationModule : Module { protected override void Load(ContainerBuilder builder) { // Controller自动注册.NET 8.0需指定程序集 builder.RegisterControllers(Assembly.GetExecutingAssembly()) .PropertiesAutowired(); // 启用属性注入如[FromServices] // 全局异常过滤器 builder.RegisterTypeGlobalExceptionFilter() .AsExceptionFilterAttribute() .SingleInstance(); // 自定义Action过滤器如权限校验 builder.RegisterTypeRoleAuthorizationFilter() .AsActionFilterAttribute() .InstancePerLifetimeScope(); } }最后在Program.cs中组合所有模块var builder WebApplication.CreateBuilder(args); // 1. 添加服务到MS.DI基础服务 builder.Services.AddControllers(); builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); // 2. 构建Autofac容器 var containerBuilder new ContainerBuilder(); containerBuilder.RegisterModuleInfrastructureModule(); containerBuilder.RegisterModuleDomainModule(); containerBuilder.RegisterModuleApplicationModule(); containerBuilder.RegisterModulePresentationModule(); // 3. 将MS.DI服务导入Autofac关键 containerBuilder.Populate(builder.Services); // 4. 构建容器并设置为ServiceProvider builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory()); builder.Host.ConfigureContainerContainerBuilder(containerBuilder.Build()); var app builder.Build();实操心得模块化注册最大的好处是“可测试性”。你可以单独实例化InfrastructureModule用new ContainerBuilder().RegisterModuleInfrastructureModule().Build()创建最小容器快速验证DbContext注册是否正确无需启动整个Web应用。我习惯在CI流水线中加入此步骤防止配置错误合并到主干。3.3 DbContext工厂模式为什么8.0之后必须用IDbContextFactoryEF Core 8.0是一个分水岭。微软正式废弃了DbContext的“构造函数注入即用”模式强制推广IDbContextFactoryT。原因很现实在高并发、长生命周期场景下直接注入DbContext极易导致连接池耗尽或状态混乱。想象一个后台任务public class OrderCleanupJob { private readonly IDbContextFactoryAppDbContext _contextFactory; public OrderCleanupJob(IDbContextFactoryAppDbContext contextFactory) { _contextFactory contextFactory; } public async Task ExecuteAsync() { // 每次需要DbContext时显式创建 await using var context await _contextFactory.CreateDbContextAsync(); var orders await context.Orders.Where(x x.Status Pending).ToListAsync(); foreach (var order in orders) { order.Status Cancelled; } await context.SaveChangesAsync(); // context自动Dispose连接归还池 } }对比旧模式危险// ❌ 危险DbContext被注入到长生命周期类中 public class OrderCleanupJob { private readonly AppDbContext _context; // Scoped生命周期但Job是Singleton public OrderCleanupJob(AppDbContext context) _context context; // 会导致_context被所有Job共享 public async Task ExecuteAsync() { // 多个Job并发执行时_context被同时访问引发异常 var orders await _context.Orders.ToListAsync(); } }Autofac中注册IDbContextFactory的要点必须注册为InstancePerLifetimeScope而非SingleInstance。因为Factory本身无状态但其创建的DbContext需绑定到当前作用域。若需在非HTTP上下文中使用如Hangfire需手动创建作用域public class HangfireJob { private readonly ILifetimeScope _scope; public HangfireJob(ILifetimeScope scope) _scope scope; public async Task ProcessOrder(int orderId) { await using var jobScope _scope.BeginLifetimeScope(hangfire-job); var factory jobScope.ResolveIDbContextFactoryAppDbContext(); await using var context await factory.CreateDbContextAsync(); // ...业务逻辑 } }注意IDbContextFactory不是银弹。它增加了代码量且每次CreateDbContextAsync()都有微小开销。但对于Web API建议仍用构造函数注入因HTTP请求天然短生命周期对于后台任务、消息队列消费者等长周期场景必须用Factory。某物流系统将所有后台服务强制切换为Factory模式后数据库连接超时率从12%降至0.3%。4. 关键环节实现与避坑指南那些文档里不会写的细节4.1 事务管理如何用Autofac实现声明式事务EF默认不支持声明式事务如Java的Transactional但Autofac的拦截器Interception可以完美模拟。核心思路在方法执行前开启事务成功则提交异常则回滚。首先定义事务特性[AttributeUsage(AttributeTargets.Method)] public class TransactionAttribute : Attribute { }然后实现拦截器public class TransactionInterceptor : IInterceptor { private readonly IDbContextFactoryAppDbContext _contextFactory; public TransactionInterceptor(IDbContextFactoryAppDbContext contextFactory) { _contextFactory contextFactory; } public void Intercept(IInvocation invocation) { // 1. 获取当前作用域确保DbContext复用 var scope invocation.InvocationTarget.GetType() .GetField(_scope, BindingFlags.NonPublic | BindingFlags.Instance) ?.GetValue(invocation.InvocationTarget) as ILifetimeScope; // 2. 创建DbContext并开启事务 var context scope?.ResolveIDbContextFactoryAppDbContext() .CreateDbContextAsync().GetAwaiter().GetResult() ?? throw new InvalidOperationException(No scope found); var transaction context.Database.BeginTransaction(); try { // 3. 执行原方法 invocation.Proceed(); // 4. 提交事务 transaction.Commit(); } catch { // 5. 回滚 transaction.Rollback(); throw; } finally { // 6. 显式Dispose避免连接泄漏 context.Dispose(); } } }注册拦截器在DomainModule中builder.RegisterTypeTransactionInterceptor().AsSelf().InstancePerLifetimeScope(); builder.RegisterTypeOrderService() .AsIOrderService() .InstancePerLifetimeScope() .EnableInterfaceInterceptors() .InterceptedBy(typeof(TransactionInterceptor));在服务方法上标记public class OrderService : IOrderService { [Transaction] // ✅ 声明式开启事务 public async Taskbool CreateOrder(OrderDto dto) { // 业务逻辑自动包含在事务中 } }避坑指南拦截器中绝不能直接注入DbContext因为拦截器是Singleton生命周期而DbContext是Scoped会导致作用域冲突。必须通过IDbContextFactory按需创建。某支付系统曾因此出现事务不生效问题排查一周才发现拦截器构造函数里写了AppDbContext context。4.2 多数据库支持如何为不同DbContext注册不同连接字符串企业级系统常需读写分离或分库分表。Autofac支持基于命名的DbContext注册// 注册主库写 builder.Register(c { var connStr c.ResolveIConfiguration().GetConnectionString(MasterDb); return new MasterDbContext(new DbContextOptionsBuilderMasterDbContext() .UseSqlServer(connStr).Options); }) .AsSelf() .NamedMasterDbContext(master) .InstancePerLifetimeScope(); // 注册从库读 builder.Register(c { var connStr c.ResolveIConfiguration().GetConnectionString(SlaveDb); return new SlaveDbContext(new DbContextOptionsBuilderSlaveDbContext() .UseSqlServer(connStr).Options); }) .AsSelf() .NamedSlaveDbContext(slave) .InstancePerLifetimeScope(); // 在仓储中按需解析 public class OrderRepository : IOrderRepository { private readonly ILifetimeScope _scope; public OrderRepository(ILifetimeScope scope) _scope scope; public async TaskOrder GetOrderById(int id) { // 读操作走从库 await using var context _scope.ResolveNamedSlaveDbContext(slave); return await context.Orders.FindAsync(id); } public async Task CreateOrder(Order order) { // 写操作走主库 await using var context _scope.ResolveNamedMasterDbContext(master); context.Orders.Add(order); await context.SaveChangesAsync(); } }实操心得命名注册后务必在Startup中验证是否注册成功。我习惯加一个健康检查端点app.MapGet(/health/db, async (HttpContext ctx) { try { var scope ctx.RequestServices.GetRequiredServiceILifetimeScope(); scope.ResolveNamedMasterDbContext(master); // 触发解析 scope.ResolveNamedSlaveDbContext(slave); await ctx.Response.WriteAsJsonAsync(new { status ok }); } catch (Exception ex) { ctx.Response.StatusCode 503; await ctx.Response.WriteAsJsonAsync(new { status error, message ex.Message }); } });4.3 性能优化连接池、查询缓存与生命周期协同EF Autofac的性能瓶颈80%源于DbContext生命周期与数据库连接池的错配。关键参数参数推荐值说明Max Pool Size200连接池最大连接数需根据服务器内存和数据库许可调整。200是SQL Server的常见上限。Min Pool Size10预热连接池避免首次请求延迟。Connection Timeout30秒超时时间需大于最长业务耗时。EnableRetryOnFailure启用自动重试瞬时故障减少人工干预。在Autofac注册中配置builder.Register(c { var connectionString c.ResolveIConfiguration().GetConnectionString(DefaultConnection); var options new DbContextOptionsBuilderAppDbContext() .UseSqlServer(connectionString, opt { opt.EnableRetryOnFailure(5, TimeSpan.FromSeconds(10), null); // 最多重试5次间隔10秒 opt.MigrationsAssembly(Your.Migrations.Assembly); }) .ConfigureWarnings(w w.Ignore(RelationalEventId.AmbientTransactionWarning)); // 忽略警告 return new AppDbContext(options.Options); }) .AsSelf() .InstancePerLifetimeScope();查询缓存优化EF Core 8.0默认启用查询缓存但需确保查询参数是可序列化的。避免在Where条件中使用DateTime.Now每次值不同缓存失效改用DateTime.UtcNow或参数化查询。独家技巧监控连接池使用率。在SQL Server中运行SELECT DB_NAME(dbid) as DatabaseName, COUNT(*) as ConnectionCount FROM sys.sysprocesses WHERE dbid 0 GROUP BY dbid;若ConnectionCount持续接近Max Pool Size说明连接未及时释放——大概率是DbContext未被正确Dispose或作用域未关闭。此时应检查Autofac注册是否遗漏InstancePerLifetimeScope或是否存在async void方法导致作用域提前结束。5. 常见问题与排查技巧实录从报错信息反推根本原因5.1 经典报错速查表报错信息根本原因排查步骤解决方案System.ObjectDisposedException: Cannot access a disposed object.DbContext在作用域结束后被访问1. 查看调用栈定位哪个方法访问了DbContext2. 检查该方法所在类的生命周期是否Singleton3. 检查是否在async void方法中使用✅ 将调用类改为Scoped✅ 确保所有async方法返回Task✅ 使用IDbContextFactory按需创建System.InvalidOperationException: A second operation started on this context before a previous operation completed.多线程并发访问同一DbContext实例1. 检查是否将DbContext注册为Singleton2. 检查是否在循环中重复调用SaveChangesAsync()未await3. 检查是否在Parallel.ForEach中共享DbContext✅ DbContext必须为Scoped或Transient✅ 所有async调用必须await✅ 禁止在并行循环中共享DbContextAutofac.Core.DependencyResolutionException: No scope with a Tag matching AutofacWebRequest is visible from the scope in which the instance was requested.Autofac未与HTTP请求作用域集成1. 检查Program.cs中是否调用UseServiceProviderFactory2. 检查是否遗漏containerBuilder.Populate(services)3. 检查Autofac.Extensions.DependencyInjection版本✅ 确保UseServiceProviderFactory在CreateBuilder后立即调用✅Populate必须在Build()前执行System.Data.SqlClient.SqlException: Timeout expired.连接池耗尽或查询超时1. 运行SQL查询检查当前连接数2. 检查是否有未关闭的DbContext如忘记using3. 检查长事务是否阻塞连接✅ 增加Max Pool Size✅ 确保所有DbContext使用using或await using✅ 优化慢查询添加索引5.2 日志诊断如何让Autofac“开口说话”Autofac默认日志级别较低需主动开启详细日志。在appsettings.json中添加{ Logging: { LogLevel: { Default: Information, Autofac: Debug, // 关键开启Autofac调试日志 Microsoft.EntityFrameworkCore.Database.Command: Information } } }关键日志解读Resolved IOrderService to OrderService表示解析成功生命周期正确。Created AppDbContext with lifetime scope AutofacWebRequest确认DbContext绑定到HTTP请求。Disposing AppDbContext作用域结束时自动Dispose正常。若看到Resolved AppDbContext to AppDbContext但无Disposing日志说明作用域未正确释放——检查是否在Middleware中未调用next()或Controller中存在async void。5.3 单元测试陷阱如何在测试中模拟Autofac作用域很多团队单元测试失败是因为没理解Autofac测试的特殊性。MS.DI测试可用new ServiceCollection().Add...但Autofac必须显式创建作用域[Test] public void CreateOrder_ShouldPersistToDatabase() { // 1. 创建测试容器 var builder new ContainerBuilder(); builder.RegisterModuleInfrastructureModule(); // 只注册基础设施 builder.RegisterModuleDomainModule(); var container builder.Build(); // 2. 创建测试作用域模拟HTTP请求 using var scope container.BeginLifetimeScope(); // 3. 解析服务 var service scope.ResolveIOrderService(); var context scope.ResolveAppDbContext(); // 4. 执行测试 var result service.CreateOrder(new OrderDto { Name Test }); // 5. 验证 Assert.IsTrue(result); Assert.AreEqual(1, context.Orders.Count()); }注意测试中不要使用内存数据库InMemory。InMemory不支持事务、不模拟连接池行为会掩盖真实问题。应使用Testcontainers启动真实SQL Server容器或使用LocalDB。某团队因长期用InMemory测试上线后才发现事务不生效损失惨重。6. 我的实际经验总结哪些配置可以抄作业哪些必须自己调写到最后说点掏心窝的话。这十年我亲手配置过37个EFAutofac项目从5人小团队到200人分布式系统。有些配置我敢说“直接抄没问题”有些则必须根据你的业务特点调整。可以直接抄的“黄金配置”DbContext注册InstancePerLifetimeScope()EnableRetryOnFailure(5, TimeSpan.FromSeconds(10), null)模块化结构Infrastructure/Domain/Application/Presentation四层每个模块职责单一健康检查端点用ResolveNamed验证多数据库连接事务拦截器IDbContextFactory 显式BeginTransaction比EF自带事务更可控必须自己调的“危险区域”Max Pool Size取决于你的服务器内存每连接约1MB和数据库许可。2核4G服务器200是安全上限32核256G可设为500。盲目调高会导致内存溢出。Min Pool Size若系统有明显波峰波谷如电商大促设为波谷期平均连接数的1.5倍避免冷启动延迟。作用域标签TagBeginLifetimeScope(hangfire-job)中的字符串必须与你的任务调度框架约定一致。Hangfire用hangfireQuartz用quartz不能混用。最后分享一个血泪教训某项目为追求“极致性能”将所有服务注册为SingleInstance包括Logger和HttpClient。结果在高并发下Logger的内部缓冲区锁竞争严重吞吐量不升反降。后来改回InstancePerLifetimeScope性能提升40%。依赖注入不是越“单例”越好而是让对象的生命周期与它的状态变化频率严格匹配。DbContext有状态所以必须短命Logger无状态但内部有缓冲所以需适度复用而HttpClient.NET官方明确要求全局单例。你现在打开编辑器照着本文的模块结构花30分钟搭好基础框架。别急着写业务先跑通健康检查、压测连接池、验证事务回滚。等这些都稳了再往上垒业务代码。这才是靠谱的节奏。