1. 先搞清楚 .NET 8 依赖注入到底解决了什么以及它和过去有什么不同如果你正在用 .NET 8 和 ASP.NET Core 开发依赖注入Dependency Injection简称 DI是你绕不开的核心机制。它不是一个新概念但在 .NET 8 里它的能力边界和易用性又往前走了一步。很多人觉得 DI 就是“new 一个对象”的替代品但它的真正价值在于解耦、可测试性和生命周期管理。简单说它让你不用在类内部硬编码依赖关系而是由框架在运行时“注入”进来。这解决了什么问题想象一下你的OrderService需要访问数据库。如果没有 DI你可能会在OrderService里直接new SqlConnection()。这带来两个麻烦一是OrderService变得难以单元测试因为无法模拟数据库连接二是如果哪天你想换成MySqlConnection就得改OrderService的代码。DI 把“创建什么连接”这个决定权从OrderService内部移到了外部配置OrderService只声明“我需要一个IDbConnection”具体给哪个实现由启动时的容器决定。在 .NET 8 和 ASP.NET Core 里DI 是开箱即用的框架本身就内置了一个轻量、高性能的 IoC控制反转容器。你不需要引入第三方库如 Autofac就能满足绝大多数场景。这篇文章不会只讲概念我会带你从零开始在一个 Web API 项目里把 DI 用起来重点放在注册、解析、生命周期、选项模式这些实际编码中天天碰到的点并解释为什么这么用以及踩坑时先看哪里。2. 环境准备与项目搭建从零创建一个 ASP.NET Core Web API动手之前先确保环境。你需要安装 .NET 8 SDK 。打开终端PowerShell, CMD, 或 Bash用以下命令创建一个新的 Web API 项目dotnet new webapi -n DiDemo -o DiDemo cd DiDemo这个命令会创建一个名为DiDemo的目录里面包含一个基础的 ASP.NET Core Web API 模板。用你喜欢的 IDE如 Visual Studio 2022, VS Code, Rider打开这个项目。项目创建后你会看到Program.cs文件。在 .NET 6 之后项目模板默认使用顶级语句Program.cs非常简洁。我们所有的服务注册都会在这里进行。先别急着写代码理解一下这个文件的结构var builder WebApplication.CreateBuilder(args); // 在这里添加服务到容器DI 容器 builder.Services.AddControllers(); // 例如builder.Services.AddScopedIMyService, MyService(); var app builder.Build(); // 配置 HTTP 请求管道 app.UseHttpsRedirection(); app.UseAuthorization(); app.MapControllers(); app.Run();关键就是builder.Services这个属性它是一个IServiceCollection接口的实例这就是我们注册服务的地方。所有通过builder.Services.AddXxx()注册的服务都会被添加到内置的 DI 容器中。3. 服务注册的核心三要素接口、实现与生命周期注册服务时你需要明确三件事服务类型通常是接口、实现类型、以及生命周期。这是 DI 最核心的部分理解错了后面全是坑。3.1 定义服务接口与实现我们先创建一个简单的服务作为例子。在项目根目录下创建Services文件夹然后添加两个文件IGreetingService.csnamespace DiDemo.Services; public interface IGreetingService { string SayHello(string name); }GreetingService.csnamespace DiDemo.Services; public class GreetingService : IGreetingService { public string SayHello(string name) { return $Hello, {name}! Welcome to .NET 8 DI.; } }这是一个典型的模式定义接口IGreetingService和它的具体实现GreetingService。业务类如控制器将依赖于接口而不是具体类。3.2 理解三种服务生命周期在Program.cs中注册服务时你必须指定生命周期。.NET DI 容器支持三种Transient瞬时每次请求从容器解析时都会创建一个新的实例。适用于轻量、无状态的服务。Scoped作用域在同一个作用域Scope内是同一个实例。对于 Web 应用每个 HTTP 请求会创建一个新的作用域。这意味着在一个请求处理过程中多次解析同一个服务得到的是同一个实例。适用于需要在一个请求内保持状态的服务如数据库上下文DbContext。Singleton单例在整个应用程序生命周期内只创建一个实例。首次请求时创建后续所有请求都共享这个实例。适用于全局配置、缓存等。在Program.cs中注册我们的服务var builder WebApplication.CreateBuilder(args); builder.Services.AddControllers(); // 注册服务这里使用 Scoped 生命周期 builder.Services.AddScopedIGreetingService, GreetingService(); var app builder.Build(); // ... 其余配置这里我选择了AddScoped。为什么对于这个简单的问候服务用Transient或Scoped都可以。但在实际项目中如果服务内部持有数据库连接或任何请求级别的状态Scoped是最安全的选择。Singleton要慎用除非你确认该服务是线程安全的并且不需要请求隔离。3.3 在控制器中注入并使用服务现在我们来使用这个服务。修改Controllers/WeatherForecastController.cs或新建一个控制器using DiDemo.Services; using Microsoft.AspNetCore.Mvc; namespace DiDemo.Controllers; [ApiController] [Route([controller])] public class GreetingController : ControllerBase { private readonly IGreetingService _greetingService; // 依赖通过构造函数注入 public GreetingController(IGreetingService greetingService) { _greetingService greetingService; } [HttpGet({name})] public ActionResultstring Get(string name) { var message _greetingService.SayHello(name); return Ok(message); } }注意GreetingController的构造函数。它声明需要一个IGreetingService类型的参数。当框架需要创建这个控制器来处理 HTTP 请求时它会去 DI 容器里查找IGreetingService的注册信息发现我们注册了GreetingService为它的实现并且是Scoped生命周期。于是容器会为当前 HTTP 请求创建一个作用域如果还没有。在这个作用域内解析IGreetingService。因为是第一次解析所以实例化一个GreetingService。将这个实例传递给GreetingController的构造函数。这就是“依赖注入”——依赖项IGreetingService由外部容器“注入”到消费者GreetingController中。运行项目 (dotnet run或 F5)在浏览器或 Postman 中访问https://localhost:PORT/greeting/World你应该会看到返回Hello, World! Welcome to .NET 8 DI.。4. 进阶用法与实战避坑指南基础跑通了但实际项目远比这复杂。下面这些点是决定你的应用是否健壮的关键。4.1 选项模式管理配置的最佳实践直接把配置字符串硬编码在服务里是糟糕的做法。.NET 提供了“选项模式”它通过 DI 来强类型化地访问配置。假设我们有一个邮件服务配置。首先在appsettings.json中添加配置{ MailSettings: { SmtpServer: smtp.example.com, Port: 587, SenderName: Notification System } }然后创建一个对应的强类型类Models/MailSettings.csnamespace DiDemo.Models; public class MailSettings { public string SmtpServer { get; set; } string.Empty; public int Port { get; set; } public string SenderName { get; set; } string.Empty; }在Program.cs中配置选项// 绑定配置到强类型类 builder.Services.ConfigureMailSettings(builder.Configuration.GetSection(MailSettings));现在在任何需要的地方你可以通过IOptionsMailSettings来注入配置Services/IMailService.cs和MailService.csusing DiDemo.Models; using Microsoft.Extensions.Options; namespace DiDemo.Services; public interface IMailService { /* ... */ } public class MailService : IMailService { private readonly MailSettings _mailSettings; // 注入 IOptionsT public MailService(IOptionsMailSettings mailOptions) { // 通过 .Value 获取配置实例 _mailSettings mailOptions.Value; // 现在可以使用 _mailSettings.SmtpServer 等 } } // 别忘了注册builder.Services.AddScopedIMailService, MailService();为什么用IOptionsT而不是直接注入MailSettings因为IOptionsT封装了配置的重新加载能力如果配置源支持热更新。直接注入MailSettings的话配置在应用启动后就被快照了无法更新。4.2 服务注册的多种方式与选择除了AddScopedInterface, Implementation()还有几种注册方式直接注册实现类builder.Services.AddScopedMyService();。当服务没有接口或者实现类自身就是抽象时使用。但这样不利于单元测试无法模拟。注册现有实例var instance new MyService(); builder.Services.AddSingleton(instance);。将已经创建好的对象加入容器作为单例。工厂方法注册builder.Services.AddScopedIService(sp new ServiceImpl( sp.GetRequiredServiceIOtherService() ));。当服务的创建逻辑复杂需要基于其他服务动态构建时使用。我的建议是只要可能优先使用接口注册。这为单元测试和未来替换实现提供了最大的灵活性。4.3 依赖注入的典型问题与排查顺序当你遇到 DI 相关错误时比如InvalidOperationException: Unable to resolve service for type...不要慌按这个顺序排查检查服务是否注册这是最常见的问题。去Program.cs里确认builder.Services中是否有对应服务的注册代码。检查拼写和命名空间。检查生命周期是否匹配这是更隐蔽的坑。切记不能将生命周期长的服务注入到生命周期短的服务中。例如错误将一个Singleton服务注入到一个Scoped服务中。这没问题。错误将一个Scoped服务注入到一个Singleton服务中。这是不允许的因为Singleton实例存活整个应用周期而它内部的Scoped依赖试图共享一个可能早已结束的请求作用域会导致行为异常或内存泄漏。框架在开发环境通常会抛出异常。检查构造函数参数确保你要注入的服务类型接口或类正是你注册的类型。如果服务有多个构造函数DI 容器会选择参数最多且都能从容器中解析的那个。检查循环依赖如果 A 依赖 BB 又依赖 A容器无法解析。需要重构代码通常引入第三个服务或使用延迟加载LazyT或IServiceProvider来打破循环但这只是缓解最好从设计上避免。使用IServiceProvider进行手动解析谨慎使用在极少数情况下你无法通过构造函数注入例如在静态方法或中间件中。可以通过注入IServiceProvider然后在需要时调用GetServiceT()或GetRequiredServiceT()。但这应该是最后的手段因为它让依赖关系变得不透明不利于测试。public class MyClass { private readonly IServiceProvider _serviceProvider; public MyClass(IServiceProvider serviceProvider) { _serviceProvider serviceProvider; } public void DoSomething() { using (var scope _serviceProvider.CreateScope()) { var scopedService scope.ServiceProvider.GetRequiredServiceIMyScopedService(); // 使用 scopedService } } }注意上面创建了作用域 (CreateScope())这是正确获取Scoped服务的方式。5. 在 .NET 8 中的新特性与性能考量.NET 8 在依赖注入方面没有翻天覆地的变化但持续在性能和开发体验上做优化。原生 AOT 兼容性如果你计划将应用发布为原生 AOT提前编译需要特别注意 DI。原生 AOT 要求所有在运行时动态创建的代码如反射必须是可分析的。这意味着一些基于反射的复杂 DI 模式可能无法工作。.NET 8 的容器对此有更好的支持但最佳实践是保持服务注册简单明了避免过于动态的注册逻辑。IHttpClientFactory的集成在 ASP.NET Core 中创建HttpClient实例强烈推荐使用IHttpClientFactory通过AddHttpClient注册它本身与 DI 深度集成能优雅地处理 DNS 刷新、连接池和生命周期问题。这比直接new HttpClient()或将其注册为Singleton要好得多。源生成器.NET 8 在一些底层库中更多地使用了源生成器来减少运行时反射提升性能。虽然这对使用者透明但它意味着遵循标准模式如选项模式的代码可能会获得更好的启动性能。对于性能一个常见的误区是过度优化 DI 容器的选择。对于绝大多数 ASP.NET Core 应用内置容器完全足够性能不是瓶颈。只有在你有非常复杂的服务图成千上万个注册、需要高级功能如子容器、基于属性的注入时才需要考虑像 Autofac 这样的第三方容器。过早引入第三方容器会增加复杂性而收益甚微。6. 总结把依赖注入用对、用稳依赖注入是构建可测试、可维护的 .NET 应用的基础设施。在 .NET 8 和 ASP.NET Core 中用好它并不难关键是遵循几个原则面向接口编程服务类依赖抽象接口而不是具体实现。明确生命周期根据服务的行为选择Transient、Scoped或Singleton。记住作用域边界避免跨生命周期依赖。构造函数注入为主这是最清晰、最可测试的注入方式。善用选项模式管理配置不要硬编码。优先使用内置容器除非有确凿证据表明它成为瓶颈否则不要引入第三方容器增加复杂度。当你遇到 DI 问题时首先回到Program.cs检查注册然后检查生命周期匹配性最后再考虑是否是循环依赖等设计问题。把这几步走通你就能在 .NET 8 项目中稳健地驾驭依赖注入让代码结构更清晰也为后续的单元测试和功能扩展打下坚实基础。