你有没有遇到过这样的场景一个看似简单的功能改动却需要修改十几个文件一个新增的业务逻辑要手动传递七八层依赖单元测试时为了构造一个对象得先实例化一堆它根本不需要的东西。在 .NET 开发中尤其是构建现代 Web 应用时这种“牵一发而动全身”的耦合问题几乎是每个开发者都会经历的阵痛。依赖注入Dependency Injection, DI正是为了解决这类问题而生的核心设计模式。它不是 .NET 8 或 ASP.NET Core 的新发明但却是它们构建现代、可测试、可维护应用架构的基石。很多人对 DI 的理解停留在“框架帮我 new 对象”的层面认为只要用了IServiceCollection.AddScoped就是依赖注入。这其实只看到了冰山一角。真正的价值在于它通过控制反转IoC将对象的创建、组装和生命周期管理从业务代码中剥离出来让应用的核心逻辑变得纯粹、独立且易于测试。在 .NET 8 和 ASP.NET Core 的语境下依赖注入框架已经深度集成功能也日趋完善。但随之而来的是更复杂的生命周期选择、更隐蔽的陷阱如作用域服务注入单例服务以及如何将 DI 思想从 Web 层贯彻到领域层、基础设施层的挑战。这篇文章不会仅仅重复官方文档的 API 列表而是试图回答几个更本质的问题在 .NET 8 的现代应用开发中依赖注入究竟改变了我们编写代码的哪些习惯面对多种服务注册方式和生命周期我们该如何做出符合场景的选择以及如何避免那些看似能用、实则埋雷的常见用法1. 重新理解依赖注入它不只是为了“方便 New 对象”很多人接触依赖注入的第一个动机是“方便”因为框架能自动解决依赖关系不用自己手动new。这没错但这只是最表层的收益。依赖注入更深层的价值在于它强制推行了一种更健康、更松耦合的代码组织方式。1.1 从“控制”到“依赖”思维的转变在没有依赖注入的传统代码中一个类如果需要另一个类的功能最常见的做法是直接在内部实例化它。// 传统紧耦合写法 public class OrderService { private readonly EmailSender _emailSender new EmailSender(); private readonly DbContext _dbContext new MyDbContext(); public void PlaceOrder(Order order) { // 业务逻辑... _dbContext.Orders.Add(order); _dbContext.SaveChanges(); _emailSender.SendConfirmation(order); } }这段代码的问题显而易见难以测试要单元测试PlaceOrder方法你无法替换EmailSender和DbContext。它们可能会真的发邮件、连数据库。难以替换如果明天想把邮件发送换成短信发送或者把 Entity Framework 换成 Dapper你需要修改OrderService的源代码。生命周期失控DbContext通常不应该以单例形式存在但在这里每个OrderService实例都创建了自己的DbContext连接管理混乱。依赖注入的核心思想是“依赖倒置”高层模块OrderService不应该依赖低层模块EmailSender,DbContext的具体实现而应该依赖它们的抽象接口。同时依赖的创建不由消费者内部完成而是由外部通常是 DI 容器“注入”。// 依赖注入写法 public interface IOrderService { void PlaceOrder(Order order); } public class OrderService : IOrderService { private readonly IEmailSender _emailSender; private readonly IAppDbContext _dbContext; // 依赖通过构造函数注入 public OrderService(IEmailSender emailSender, IAppDbContext dbContext) { _emailSender emailSender; _dbContext dbContext; } public void PlaceOrder(Order order) { // 业务逻辑不变但依赖是抽象的 _dbContext.Orders.Add(order); _dbContext.SaveChanges(); _emailSender.SendConfirmation(order); } }这个转变的关键在于OrderService不再关心IEmailSender和IAppDbContext是谁、怎么来的。它只声明“我需要这些功能”。至于具体是哪个实现类来提供这些功能是在应用启动时通过 DI 容器配置决定的。1.2 .NET 8 中 DI 容器的角色不仅仅是注册表在 ASP.NET Core 中IServiceCollection就是我们的 DI 容器配置入口。很多人把它当作一个简单的“服务注册表”但它的角色更接近于一个“组件装配说明书”。// Program.cs 或 Startup.cs var builder WebApplication.CreateBuilder(args); // 装配说明书当需要 IEmailSender 时请使用 SmtpEmailSender builder.Services.AddScopedIEmailSender, SmtpEmailSender(); // 当需要 IAppDbContext 时请使用 MyDbContext并确保它按作用域生命周期管理 builder.Services.AddDbContextMyDbContext(options options.UseSqlServer(builder.Configuration.GetConnectionString(DefaultConnection))); // 注册 OrderService 自身 builder.Services.AddScopedIOrderService, OrderService();DI 容器ServiceProvider在运行时根据这份“说明书”自动解析依赖树创建对象并管理它们的生命周期。这个过程对业务代码是完全透明的。这种设计带来的最大好处是可测试性在单元测试中你可以轻松注入模拟Mock对象。// 单元测试示例 [Test] public void PlaceOrder_Should_SaveToDb_And_SendEmail() { // 1. 创建模拟对象 var mockDb new MockIAppDbContext(); var mockEmail new MockIEmailSender(); // 设置模拟行为... // 2. 注入模拟对象而不是真实实现 var orderService new OrderService(mockEmail.Object, mockDb.Object); var testOrder new Order(); // 3. 执行测试 orderService.PlaceOrder(testOrder); // 4. 验证交互 mockDb.Verify(db db.SaveChanges(), Times.Once); mockEmail.Verify(e e.SendConfirmation(testOrder), Times.Once); }所以依赖注入在 .NET 8 中的首要价值是推动我们写出面向接口、职责清晰、易于测试的代码结构。它通过技术手段强制改善了代码的设计质量。2. 生命周期的选择Scoped, Singleton, Transient 不是随便选的生命周期管理是 DI 框架的核心能力也是最容易用错的地方。.NET 8 的 DI 容器提供了三种基本生命周期瞬时Transient、作用域Scoped和单例Singleton。选择哪种不是凭感觉而是由服务的用途和资源特性决定的。2.1 三种生命周期的本质区别生命周期创建时机典型场景注意事项瞬时 (Transient)每次从容器请求时都会创建一个新实例。无状态服务、轻量级工具类如Random,DateTimeProvider、每次操作都需要全新状态的处理器。频繁创建可能对性能有轻微影响。确保服务本身是轻量的且没有对昂贵资源如数据库连接的依赖。作用域 (Scoped)在一个作用域 (Scope)内是单例。对于 Web 应用通常一个 HTTP 请求就是一个作用域。最常用。需要在一个“工作单元”内保持状态一致性的服务如DbContextEntity Framework Core、仓储Repository、具有请求级缓存的服务。绝对不要将 Scoped 服务注入到 Singleton 服务中这会导致 Scoped 服务在 Singleton 生命周期内“升格”为事实上的 Singleton引发并发和数据混乱问题。单例 (Singleton)在应用程序的整个生命周期内只存在一个实例。全局配置、缓存服务如IMemoryCache、后台任务调度器、连接池、日志器如ILoggerT。必须是线程安全的。避免在 Singleton 中持有 Scoped 或 Transient 服务的引用。在 ASP.NET Core 中作用域的生命周期与 HTTP 请求绑定这是理解许多行为的关键。当一个请求到来时框架会创建一个新的作用域IServiceScope。在这个作用域内解析的所有 Scoped 服务都是同一个实例。请求结束时作用域被释放其中所有实现了IDisposable接口的 Scoped 和 Transient 服务都会被 Dispose。2.2 真实场景下的生命周期决策让我们通过一个电商场景来理解生命周期的选择// 配置服务 builder.Services.AddSingletonICacheService, DistributedCacheService(); // 全局缓存单例 builder.Services.AddScopedIShoppingCartRepository, ShoppingCartRepository(); // 购物车与用户会话相关作用域 builder.Services.AddScopedIOrderProcessingService, OrderProcessingService(); // 订单处理涉及事务作用域 builder.Services.AddTransientIEmailTemplateRenderer, RazorEmailTemplateRenderer(); // 模板渲染无状态瞬时 builder.Services.AddDbContextAppDbContext(options ...); // DbContext 默认注册为 Scoped为什么DbContext必须是 Scoped因为 Entity Framework Core 的DbContext内部有变更跟踪器Change Tracker。如果一个DbContext实例被多个请求共享Singleton或者在一个长生命周期任务中持续使用变更跟踪器会累积大量实体导致内存泄漏和并发冲突。Scoped 生命周期确保每个请求都有自己的DbContext请求结束时自动清理完美契合“工作单元”模式。为什么ILoggerT是 Singleton日志记录通常是无状态的并且创建日志器开销较大。将其设为单例所有请求共享同一个实例性能更优。ILoggerT的实现本身是线程安全的。注意一个常见的陷阱是在Program.cs或Startup.cs中通过ApplicationServices根容器去解析一个 Scoped 服务。这会导致该 Scoped 服务被提升为 Singleton因为它被根容器持有。正确做法是在一个明确的作用域内解析。// 错误做法 var scopedService app.Services.GetRequiredServiceIMyScopedService(); // 危险 // 正确做法 using (var scope app.Services.CreateScope()) { var scopedService scope.ServiceProvider.GetRequiredServiceIMyScopedService(); // 使用 scopedService }2.3 自定义生命周期与IDisposable对于实现了IDisposable接口的服务DI 容器会自动在服务生命周期结束时调用Dispose方法。这是管理非托管资源如文件句柄、网络连接的关键。Transient IDisposable每次请求都会创建新实例并在请求结束时对于从 Scoped 或 Request 中解析的或容器释放时对于从根容器解析的被 Dispose。如果创建非常频繁需注意性能。Scoped IDisposable每个作用域一个实例作用域结束时被 Dispose。这是最符合直觉的。Singleton IDisposable应用关闭时容器会 Dispose 单例服务。但如果单例服务持有需要更早释放的资源就需要更精细的控制。生命周期的选择本质是对服务状态、资源管理和并发安全性的权衡。在不确定时优先选择Scoped因为它最安全且与 Web 请求的自然边界对齐。3. 超越基础注册工厂模式、选项模式与第三方容器集成基础的AddScopedTService, TImplementation能满足大部分需求但 .NET 8 的 DI 容器提供了更灵活的方式来应对复杂场景。3.1 使用工厂方法进行条件性注册有时服务的具体实现需要在运行时根据条件决定。这时可以使用AddSingleton/AddScoped/AddTransient的重载接受一个工厂委托。builder.Services.AddScopedIPaymentGateway(serviceProvider { var config serviceProvider.GetRequiredServiceIConfiguration(); var country config[StoreSettings:DefaultCountry]; return country switch { US new StripePaymentGateway(), EU new AdyenPaymentGateway(), _ new DefaultPaymentGateway() }; });工厂方法内部可以通过serviceProvider参数解析其他已注册的服务如上面的IConfiguration这让你能在决定最终实现时考虑应用的其他状态。3.2 拥抱选项模式Options Pattern进行配置注入直接将IConfiguration注入到业务服务中会让服务与配置结构紧耦合。.NET 提供的选项模式是更好的选择。定义强类型配置类public class SmtpSettings { public const string SectionName SmtpSettings; public string Host { get; set; } public int Port { get; set; } public string UserName { get; set; } public string Password { get; set; } }在appsettings.json中配置{ SmtpSettings: { Host: smtp.example.com, Port: 587, UserName: userexample.com, Password: your-password } }注册并绑定配置builder.Services.ConfigureSmtpSettings( builder.Configuration.GetSection(SmtpSettings.SectionName));通过IOptionsT/IOptionsSnapshotT/IOptionsMonitorT注入使用public class EmailService : IEmailService { private readonly SmtpSettings _settings; // 使用 IOptionsSnapshot 可以在请求内获取最新配置Scoped public EmailService(IOptionsSnapshotSmtpSettings options) { _settings options.Value; // 直接访问强类型配置 } // ... 使用 _settings.Host 等 }IOptionsSnapshotT在 Scoped 生命周期内提供一致的配置值并且如果配置源支持热重载如文件它能感知到变化。IOptionsMonitorT是 Singleton可用于监听配置变更。选项模式将配置验证、管理和使用清晰地分离开是生产级应用的标配。3.3 集成第三方容器如 Autofac内置容器功能强大且性能优异足以应对 95% 的场景。但在需要更高级功能时如基于属性的注入、子容器、动态代理/AOP可以考虑集成第三方容器如 Autofac。在 .NET 8 中集成通常很简单// 1. 安装 NuGet 包Autofac.Extensions.DependencyInjection var builder WebApplication.CreateBuilder(args); // 2. 告诉 ASP.NET Core 使用 Autofac 作为服务提供者工厂 builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory()); // 3. 在 Autofac 的 ContainerBuilder 中配置模块 builder.Host.ConfigureContainerContainerBuilder(containerBuilder { // 可以继续使用 .NET 原生方式注册也可以使用 Autofac 语法 containerBuilder.RegisterModule(new MyApplicationModule()); });是否需要第三方容器我的建议是除非内置容器无法满足你的特定需求例如你需要基于程序集的自动批量注册复杂约定或深度使用拦截器进行 AOP否则优先使用内置容器。它的集成度更高维护更简单且被整个 .NET 团队深度优化。4. 架构实践在分层应用中正确使用依赖注入依赖注入不应只停留在 Web API 的 Controller 层。一个清晰的分层架构如清洁架构、分层架构中每一层都应该利用 DI 来管理依赖。4.1 依赖方向与项目引用一个典型的分层结构可能是Presentation (Web API) 依赖于 Application 和 Infrastructure通过接口。Application 包含用例和业务逻辑依赖于 Domain 和 Infrastructure通过接口。Domain 核心业务模型和规则不依赖任何外部层。Infrastructure 实现持久化、外部服务调用等依赖于 Domain并实现 Application 层定义的接口。关键原则依赖指向抽象并且指向内层稳定层。这意味着Web 层不直接引用 Infrastructure 的具体项目如EntityFrameworkCore而是引用其抽象接口所在的程序集。所有具体的实现注册应该集中在组合根Composition Root通常是 Web 项目的Program.cs或一个专门的DependencyInjection类中。4.2 使用扩展方法组织注册逻辑为了避免Program.cs变成一个庞大的注册列表可以为每一层或每个模块创建扩展方法。// 在 Infrastructure 项目中 public static class InfrastructureServiceRegistration { public static IServiceCollection AddInfrastructureServices( this IServiceCollection services, IConfiguration configuration) { services.AddDbContextAppDbContext(options options.UseSqlServer(configuration.GetConnectionString(DefaultConnection))); services.AddScoped(typeof(IAsyncRepository), typeof(RepositoryBase)); services.AddScopedIOrderRepository, OrderRepository(); services.AddScopedIUnitOfWork, UnitOfWork(); // 注册其他基础设施服务如缓存、消息队列客户端等 services.AddStackExchangeRedisCache(options ...); services.AddScopedIEmailService, SmtpEmailService(); return services; } } // 在 Application 项目中 public static class ApplicationServiceRegistration { public static IServiceCollection AddApplicationServices(this IServiceCollection services) { services.AddAutoMapper(Assembly.GetExecutingAssembly()); // 注册 AutoMapper services.AddMediatR(cfg cfg.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly())); // 注册 MediatR services.AddScopedIOrderService, OrderService(); // 注册其他应用服务 return services; } } // 在 Web API 项目的 Program.cs 中 builder.Services.AddApplicationServices(); builder.Services.AddInfrastructureServices(builder.Configuration);这种方式让注册逻辑模块化、可维护并且清晰地展示了应用的依赖结构。4.3 处理循环依赖循环依赖A 依赖 BB 又依赖 A是糟糕设计的标志DI 容器通常也无法解析它。如果遇到首先应该重新审视设计看是否能通过引入第三个抽象、合并逻辑或应用中介者模式如 MediatR来打破循环。如果因某些原因暂时无法重构.NET 8 的 DI 容器支持使用LazyT或FuncT进行延迟解析来打破编译期循环但这只是权宜之计应标注为待解决的技术债务。// 不推荐仅作示例 public class ServiceA { private readonly LazyServiceB _b; public ServiceA(LazyServiceB b) _b b; public void Method() _b.Value.DoSomething(); }依赖注入的最终目标是让应用程序像一套精密的乐高积木。每个模块乐高块通过标准的接口凸起和凹槽声明自己的依赖和能提供的功能。DI 容器则是按照图纸注册代码将它们组装成最终形态的工程师。在 .NET 8 和 ASP.NET Core 的生态中熟练掌握这套组装技术意味着你能构建出更灵活、更健壮、也更能适应未来变化的应用系统。它从一种“框架提供的便利”变成了塑造现代 .NET 应用架构的核心思维模式。
.NET 8依赖注入深度解析：从原理到架构实践
你有没有遇到过这样的场景一个看似简单的功能改动却需要修改十几个文件一个新增的业务逻辑要手动传递七八层依赖单元测试时为了构造一个对象得先实例化一堆它根本不需要的东西。在 .NET 开发中尤其是构建现代 Web 应用时这种“牵一发而动全身”的耦合问题几乎是每个开发者都会经历的阵痛。依赖注入Dependency Injection, DI正是为了解决这类问题而生的核心设计模式。它不是 .NET 8 或 ASP.NET Core 的新发明但却是它们构建现代、可测试、可维护应用架构的基石。很多人对 DI 的理解停留在“框架帮我 new 对象”的层面认为只要用了IServiceCollection.AddScoped就是依赖注入。这其实只看到了冰山一角。真正的价值在于它通过控制反转IoC将对象的创建、组装和生命周期管理从业务代码中剥离出来让应用的核心逻辑变得纯粹、独立且易于测试。在 .NET 8 和 ASP.NET Core 的语境下依赖注入框架已经深度集成功能也日趋完善。但随之而来的是更复杂的生命周期选择、更隐蔽的陷阱如作用域服务注入单例服务以及如何将 DI 思想从 Web 层贯彻到领域层、基础设施层的挑战。这篇文章不会仅仅重复官方文档的 API 列表而是试图回答几个更本质的问题在 .NET 8 的现代应用开发中依赖注入究竟改变了我们编写代码的哪些习惯面对多种服务注册方式和生命周期我们该如何做出符合场景的选择以及如何避免那些看似能用、实则埋雷的常见用法1. 重新理解依赖注入它不只是为了“方便 New 对象”很多人接触依赖注入的第一个动机是“方便”因为框架能自动解决依赖关系不用自己手动new。这没错但这只是最表层的收益。依赖注入更深层的价值在于它强制推行了一种更健康、更松耦合的代码组织方式。1.1 从“控制”到“依赖”思维的转变在没有依赖注入的传统代码中一个类如果需要另一个类的功能最常见的做法是直接在内部实例化它。// 传统紧耦合写法 public class OrderService { private readonly EmailSender _emailSender new EmailSender(); private readonly DbContext _dbContext new MyDbContext(); public void PlaceOrder(Order order) { // 业务逻辑... _dbContext.Orders.Add(order); _dbContext.SaveChanges(); _emailSender.SendConfirmation(order); } }这段代码的问题显而易见难以测试要单元测试PlaceOrder方法你无法替换EmailSender和DbContext。它们可能会真的发邮件、连数据库。难以替换如果明天想把邮件发送换成短信发送或者把 Entity Framework 换成 Dapper你需要修改OrderService的源代码。生命周期失控DbContext通常不应该以单例形式存在但在这里每个OrderService实例都创建了自己的DbContext连接管理混乱。依赖注入的核心思想是“依赖倒置”高层模块OrderService不应该依赖低层模块EmailSender,DbContext的具体实现而应该依赖它们的抽象接口。同时依赖的创建不由消费者内部完成而是由外部通常是 DI 容器“注入”。// 依赖注入写法 public interface IOrderService { void PlaceOrder(Order order); } public class OrderService : IOrderService { private readonly IEmailSender _emailSender; private readonly IAppDbContext _dbContext; // 依赖通过构造函数注入 public OrderService(IEmailSender emailSender, IAppDbContext dbContext) { _emailSender emailSender; _dbContext dbContext; } public void PlaceOrder(Order order) { // 业务逻辑不变但依赖是抽象的 _dbContext.Orders.Add(order); _dbContext.SaveChanges(); _emailSender.SendConfirmation(order); } }这个转变的关键在于OrderService不再关心IEmailSender和IAppDbContext是谁、怎么来的。它只声明“我需要这些功能”。至于具体是哪个实现类来提供这些功能是在应用启动时通过 DI 容器配置决定的。1.2 .NET 8 中 DI 容器的角色不仅仅是注册表在 ASP.NET Core 中IServiceCollection就是我们的 DI 容器配置入口。很多人把它当作一个简单的“服务注册表”但它的角色更接近于一个“组件装配说明书”。// Program.cs 或 Startup.cs var builder WebApplication.CreateBuilder(args); // 装配说明书当需要 IEmailSender 时请使用 SmtpEmailSender builder.Services.AddScopedIEmailSender, SmtpEmailSender(); // 当需要 IAppDbContext 时请使用 MyDbContext并确保它按作用域生命周期管理 builder.Services.AddDbContextMyDbContext(options options.UseSqlServer(builder.Configuration.GetConnectionString(DefaultConnection))); // 注册 OrderService 自身 builder.Services.AddScopedIOrderService, OrderService();DI 容器ServiceProvider在运行时根据这份“说明书”自动解析依赖树创建对象并管理它们的生命周期。这个过程对业务代码是完全透明的。这种设计带来的最大好处是可测试性在单元测试中你可以轻松注入模拟Mock对象。// 单元测试示例 [Test] public void PlaceOrder_Should_SaveToDb_And_SendEmail() { // 1. 创建模拟对象 var mockDb new MockIAppDbContext(); var mockEmail new MockIEmailSender(); // 设置模拟行为... // 2. 注入模拟对象而不是真实实现 var orderService new OrderService(mockEmail.Object, mockDb.Object); var testOrder new Order(); // 3. 执行测试 orderService.PlaceOrder(testOrder); // 4. 验证交互 mockDb.Verify(db db.SaveChanges(), Times.Once); mockEmail.Verify(e e.SendConfirmation(testOrder), Times.Once); }所以依赖注入在 .NET 8 中的首要价值是推动我们写出面向接口、职责清晰、易于测试的代码结构。它通过技术手段强制改善了代码的设计质量。2. 生命周期的选择Scoped, Singleton, Transient 不是随便选的生命周期管理是 DI 框架的核心能力也是最容易用错的地方。.NET 8 的 DI 容器提供了三种基本生命周期瞬时Transient、作用域Scoped和单例Singleton。选择哪种不是凭感觉而是由服务的用途和资源特性决定的。2.1 三种生命周期的本质区别生命周期创建时机典型场景注意事项瞬时 (Transient)每次从容器请求时都会创建一个新实例。无状态服务、轻量级工具类如Random,DateTimeProvider、每次操作都需要全新状态的处理器。频繁创建可能对性能有轻微影响。确保服务本身是轻量的且没有对昂贵资源如数据库连接的依赖。作用域 (Scoped)在一个作用域 (Scope)内是单例。对于 Web 应用通常一个 HTTP 请求就是一个作用域。最常用。需要在一个“工作单元”内保持状态一致性的服务如DbContextEntity Framework Core、仓储Repository、具有请求级缓存的服务。绝对不要将 Scoped 服务注入到 Singleton 服务中这会导致 Scoped 服务在 Singleton 生命周期内“升格”为事实上的 Singleton引发并发和数据混乱问题。单例 (Singleton)在应用程序的整个生命周期内只存在一个实例。全局配置、缓存服务如IMemoryCache、后台任务调度器、连接池、日志器如ILoggerT。必须是线程安全的。避免在 Singleton 中持有 Scoped 或 Transient 服务的引用。在 ASP.NET Core 中作用域的生命周期与 HTTP 请求绑定这是理解许多行为的关键。当一个请求到来时框架会创建一个新的作用域IServiceScope。在这个作用域内解析的所有 Scoped 服务都是同一个实例。请求结束时作用域被释放其中所有实现了IDisposable接口的 Scoped 和 Transient 服务都会被 Dispose。2.2 真实场景下的生命周期决策让我们通过一个电商场景来理解生命周期的选择// 配置服务 builder.Services.AddSingletonICacheService, DistributedCacheService(); // 全局缓存单例 builder.Services.AddScopedIShoppingCartRepository, ShoppingCartRepository(); // 购物车与用户会话相关作用域 builder.Services.AddScopedIOrderProcessingService, OrderProcessingService(); // 订单处理涉及事务作用域 builder.Services.AddTransientIEmailTemplateRenderer, RazorEmailTemplateRenderer(); // 模板渲染无状态瞬时 builder.Services.AddDbContextAppDbContext(options ...); // DbContext 默认注册为 Scoped为什么DbContext必须是 Scoped因为 Entity Framework Core 的DbContext内部有变更跟踪器Change Tracker。如果一个DbContext实例被多个请求共享Singleton或者在一个长生命周期任务中持续使用变更跟踪器会累积大量实体导致内存泄漏和并发冲突。Scoped 生命周期确保每个请求都有自己的DbContext请求结束时自动清理完美契合“工作单元”模式。为什么ILoggerT是 Singleton日志记录通常是无状态的并且创建日志器开销较大。将其设为单例所有请求共享同一个实例性能更优。ILoggerT的实现本身是线程安全的。注意一个常见的陷阱是在Program.cs或Startup.cs中通过ApplicationServices根容器去解析一个 Scoped 服务。这会导致该 Scoped 服务被提升为 Singleton因为它被根容器持有。正确做法是在一个明确的作用域内解析。// 错误做法 var scopedService app.Services.GetRequiredServiceIMyScopedService(); // 危险 // 正确做法 using (var scope app.Services.CreateScope()) { var scopedService scope.ServiceProvider.GetRequiredServiceIMyScopedService(); // 使用 scopedService }2.3 自定义生命周期与IDisposable对于实现了IDisposable接口的服务DI 容器会自动在服务生命周期结束时调用Dispose方法。这是管理非托管资源如文件句柄、网络连接的关键。Transient IDisposable每次请求都会创建新实例并在请求结束时对于从 Scoped 或 Request 中解析的或容器释放时对于从根容器解析的被 Dispose。如果创建非常频繁需注意性能。Scoped IDisposable每个作用域一个实例作用域结束时被 Dispose。这是最符合直觉的。Singleton IDisposable应用关闭时容器会 Dispose 单例服务。但如果单例服务持有需要更早释放的资源就需要更精细的控制。生命周期的选择本质是对服务状态、资源管理和并发安全性的权衡。在不确定时优先选择Scoped因为它最安全且与 Web 请求的自然边界对齐。3. 超越基础注册工厂模式、选项模式与第三方容器集成基础的AddScopedTService, TImplementation能满足大部分需求但 .NET 8 的 DI 容器提供了更灵活的方式来应对复杂场景。3.1 使用工厂方法进行条件性注册有时服务的具体实现需要在运行时根据条件决定。这时可以使用AddSingleton/AddScoped/AddTransient的重载接受一个工厂委托。builder.Services.AddScopedIPaymentGateway(serviceProvider { var config serviceProvider.GetRequiredServiceIConfiguration(); var country config[StoreSettings:DefaultCountry]; return country switch { US new StripePaymentGateway(), EU new AdyenPaymentGateway(), _ new DefaultPaymentGateway() }; });工厂方法内部可以通过serviceProvider参数解析其他已注册的服务如上面的IConfiguration这让你能在决定最终实现时考虑应用的其他状态。3.2 拥抱选项模式Options Pattern进行配置注入直接将IConfiguration注入到业务服务中会让服务与配置结构紧耦合。.NET 提供的选项模式是更好的选择。定义强类型配置类public class SmtpSettings { public const string SectionName SmtpSettings; public string Host { get; set; } public int Port { get; set; } public string UserName { get; set; } public string Password { get; set; } }在appsettings.json中配置{ SmtpSettings: { Host: smtp.example.com, Port: 587, UserName: userexample.com, Password: your-password } }注册并绑定配置builder.Services.ConfigureSmtpSettings( builder.Configuration.GetSection(SmtpSettings.SectionName));通过IOptionsT/IOptionsSnapshotT/IOptionsMonitorT注入使用public class EmailService : IEmailService { private readonly SmtpSettings _settings; // 使用 IOptionsSnapshot 可以在请求内获取最新配置Scoped public EmailService(IOptionsSnapshotSmtpSettings options) { _settings options.Value; // 直接访问强类型配置 } // ... 使用 _settings.Host 等 }IOptionsSnapshotT在 Scoped 生命周期内提供一致的配置值并且如果配置源支持热重载如文件它能感知到变化。IOptionsMonitorT是 Singleton可用于监听配置变更。选项模式将配置验证、管理和使用清晰地分离开是生产级应用的标配。3.3 集成第三方容器如 Autofac内置容器功能强大且性能优异足以应对 95% 的场景。但在需要更高级功能时如基于属性的注入、子容器、动态代理/AOP可以考虑集成第三方容器如 Autofac。在 .NET 8 中集成通常很简单// 1. 安装 NuGet 包Autofac.Extensions.DependencyInjection var builder WebApplication.CreateBuilder(args); // 2. 告诉 ASP.NET Core 使用 Autofac 作为服务提供者工厂 builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory()); // 3. 在 Autofac 的 ContainerBuilder 中配置模块 builder.Host.ConfigureContainerContainerBuilder(containerBuilder { // 可以继续使用 .NET 原生方式注册也可以使用 Autofac 语法 containerBuilder.RegisterModule(new MyApplicationModule()); });是否需要第三方容器我的建议是除非内置容器无法满足你的特定需求例如你需要基于程序集的自动批量注册复杂约定或深度使用拦截器进行 AOP否则优先使用内置容器。它的集成度更高维护更简单且被整个 .NET 团队深度优化。4. 架构实践在分层应用中正确使用依赖注入依赖注入不应只停留在 Web API 的 Controller 层。一个清晰的分层架构如清洁架构、分层架构中每一层都应该利用 DI 来管理依赖。4.1 依赖方向与项目引用一个典型的分层结构可能是Presentation (Web API) 依赖于 Application 和 Infrastructure通过接口。Application 包含用例和业务逻辑依赖于 Domain 和 Infrastructure通过接口。Domain 核心业务模型和规则不依赖任何外部层。Infrastructure 实现持久化、外部服务调用等依赖于 Domain并实现 Application 层定义的接口。关键原则依赖指向抽象并且指向内层稳定层。这意味着Web 层不直接引用 Infrastructure 的具体项目如EntityFrameworkCore而是引用其抽象接口所在的程序集。所有具体的实现注册应该集中在组合根Composition Root通常是 Web 项目的Program.cs或一个专门的DependencyInjection类中。4.2 使用扩展方法组织注册逻辑为了避免Program.cs变成一个庞大的注册列表可以为每一层或每个模块创建扩展方法。// 在 Infrastructure 项目中 public static class InfrastructureServiceRegistration { public static IServiceCollection AddInfrastructureServices( this IServiceCollection services, IConfiguration configuration) { services.AddDbContextAppDbContext(options options.UseSqlServer(configuration.GetConnectionString(DefaultConnection))); services.AddScoped(typeof(IAsyncRepository), typeof(RepositoryBase)); services.AddScopedIOrderRepository, OrderRepository(); services.AddScopedIUnitOfWork, UnitOfWork(); // 注册其他基础设施服务如缓存、消息队列客户端等 services.AddStackExchangeRedisCache(options ...); services.AddScopedIEmailService, SmtpEmailService(); return services; } } // 在 Application 项目中 public static class ApplicationServiceRegistration { public static IServiceCollection AddApplicationServices(this IServiceCollection services) { services.AddAutoMapper(Assembly.GetExecutingAssembly()); // 注册 AutoMapper services.AddMediatR(cfg cfg.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly())); // 注册 MediatR services.AddScopedIOrderService, OrderService(); // 注册其他应用服务 return services; } } // 在 Web API 项目的 Program.cs 中 builder.Services.AddApplicationServices(); builder.Services.AddInfrastructureServices(builder.Configuration);这种方式让注册逻辑模块化、可维护并且清晰地展示了应用的依赖结构。4.3 处理循环依赖循环依赖A 依赖 BB 又依赖 A是糟糕设计的标志DI 容器通常也无法解析它。如果遇到首先应该重新审视设计看是否能通过引入第三个抽象、合并逻辑或应用中介者模式如 MediatR来打破循环。如果因某些原因暂时无法重构.NET 8 的 DI 容器支持使用LazyT或FuncT进行延迟解析来打破编译期循环但这只是权宜之计应标注为待解决的技术债务。// 不推荐仅作示例 public class ServiceA { private readonly LazyServiceB _b; public ServiceA(LazyServiceB b) _b b; public void Method() _b.Value.DoSomething(); }依赖注入的最终目标是让应用程序像一套精密的乐高积木。每个模块乐高块通过标准的接口凸起和凹槽声明自己的依赖和能提供的功能。DI 容器则是按照图纸注册代码将它们组装成最终形态的工程师。在 .NET 8 和 ASP.NET Core 的生态中熟练掌握这套组装技术意味着你能构建出更灵活、更健壮、也更能适应未来变化的应用系统。它从一种“框架提供的便利”变成了塑造现代 .NET 应用架构的核心思维模式。