.NET Core依赖注入生命周期详解与自动注入实战

先聊个场景。我最近在重构一个内部服务项目打开 Startup.cs 一看好家伙十几行services.AddScopedIUserService, UserService()排在那里往下翻还有 AddSingleton、AddTransient数了一下快四十个服务。这种代码不是不能跑但每次加一个服务就要去改注册类漏一次就是运行时才炸出来的InvalidOperationException而且团队里有人把生命周期标错比如在 Singleton 里注入 Scoped查起来真的头大。所以今天想好好聊聊 .NET Core 依赖注入里的生命周期以及怎么用自动注入的方式把服务注册这块彻底从手工劳动里解放出来。文章会先把生命周期这三个选项讲透再说清楚自动注入的思路和完整实现最后把我实际踩过的坑和排查方法整理出来。如果你是刚上手 .NET Core 的开发者或者项目里服务数量已经多到手写注册明显吃力这篇应该能帮你省下不少时间。1. 依赖注入生命周期到底解决什么问题1.1 三种生命周期不能用“存活时间”来理解网上讲生命周期基本都会说 Singleton 全局唯一、Scoped 请求内唯一、Transient 每次获取都新建这个说法没毛病但很容易让人误以为只是“活得长不长”的区别。实际上生命周期选择的核心矛盾是对象被创建之后它依赖的那些对象能不能安全地继续被追踪。我习惯用“窗口”来理解。Singleton 的窗口是整个应用进程Scoped 的窗口是当前这一个作用域Web 应用里通常就是一个 HTTP 请求Transient 没有窗口谁要谁拿新的。窗口决定了谁可以安全地注入谁——只能把窗口更短的对象注入到窗口更长的对象里反过来就是拿长窗口的对象去填短窗口的依赖就会出现“请求都结束了但那个 Singleton 还攥着一个早该销毁的 Scoped 实例”这种状态。三种生命周期的具体差异我整理成了一张表格生命周期实例唯一性范围释放时机典型使用场景容易踩的坑Singleton整个进程唯一应用停止时配置对象、日志器、内存缓存、无状态工具类不能注入 Scoped/Transient容易变成全局状态容器Scoped每个作用域唯一作用域结束时DbContext、请求级别的业务服务、工作单元在 Singleton 里被捕获Captive DependencyTransient每次解析都是新实例由容器在作用域结束时统一释放轻量级无状态服务、需要隔离状态的对象创建频繁时性能开销若内部持有 IDisposable 需注意释放时机1.2 牵扯到 DbContext 和内存缓存的决策建议项目里最常纠结的就是 Service、Repository、DbContext 到底怎么定。我给一个可以“抄作业”的思路这套判断方法在多数业务项目里都能直接用DbContext无脑 Scoped。EF Core 的变更跟踪器本来就不是线程安全的跨请求复用极易出现脏跟踪和并发问题而每次 new 又太浪费连接。Scoped 让同一个请求内的所有服务共享同一个上下文事务和工作单元都好做。业务 Service、领域服务如果 Service 内部要查数据库它必然依赖 DbContext所以也得是 Scoped如果这个 Service 只做纯计算不碰任何有状态依赖可以 Transient。缓存、配置、日志、序列化Singleton 没问题但前提是内部不依赖 Scoped。HttpClient别用 Transient 裸 new官方推荐用 IHttpClientFactory 管理它内部按命名客户端做 Singleton 的 Handler 复用道理和 DI 生命周期是相通的。我见过一个真实案例有人把某个“数据字典 Service”注册成 Singleton里面注入了一个内存缓存看起来挺正常。结果那个 Service 的构造函数里还偷偷注入了 DbContext 的派生类问题就来了第一个请求把它创建出来之后DbContext 被固定在那一个请求的 scope 里后来那个 scope 销毁了这个 Singleton 还在工作一查数据库就抛DbContext has been disposed。这不是代码报错奇怪而是生命周期选错了。1.3 生命周期验证开关让问题早起报ASP.NET Core 从 3.0 开始默认在开发环境启用了ValidateScopes和ValidateOnBuild这就是为了拦截“Singleton 里注入 Scoped”这种事。ValidateScopes会在每次解析时校验作用域是否正确ValidateOnBuild则在应用启动构建容器时就跑一遍完整校验。我建议在开发环境保持默认开启但生产环境如果是控制台应用、后台任务这类自己创建 scope 的场景也别图省事关掉。很多“偶发崩溃”其实都是关闭校验后把错误推迟到运行期才爆出来。动手配置的方式很简单var builder WebApplication.CreateBuilder(args); // 开发环境默认开生产环境可以按需显式声明 builder.Host.UseDefaultServiceProvider(options { options.ValidateScopes true; options.ValidateOnBuild true; });有一个容易被忽略的细节ValidateOnBuild只校验容器构建时能静态发现的错误比如构造函数的依赖是否都能解析。它不能发现“你解析了一个 Singleton而这个 Singleton 的依赖链里藏着一个 Scoped”这种问题这类问题还是得靠ValidateScopes在运行时捕获。2. 为什么需要自动注入思路拆解2.1 手写注册的本质是重复劳动而且容易漏手写services.AddXXXTInterface, TImplementation()表面上是“也没几行”但它的真正成本不在写而在维护。每新增一个服务要实现三个动作建接口、建实现类、去注册类里加一行。这三个动作一旦拆开就必然出现“接口建了但忘注册”的情况。项目小的时候这算不上事但当服务超过二三十个注册代码就会变成一堵“全是重复格式的墙”看多了眼睛疼而且代码评审时很难注意到某一行是不是把生命周期写错了。自动注入要解决的就是不让你手动去维护那堵墙。它把你从“记得去注册”这件事里解放出来只保留一个动作写接口和实现的时候顺手标记一下生命周期。剩下的扫描、匹配、注册全部由代码完成。2.2 约定优先标记接口和特性的取舍做自动注入关键问题是怎么告诉容器“这个类要注册成什么生命周期”。目前团队里主流做法有两种我分别说下适用场景。第一种是空标记接口定义长这样public interface ITransientDependency { } public interface IScopedDependency { } public interface ISingletonDependency { }约定是UserService : IUserService, IScopedDependency。注册器扫描到某个类实现了IScopedDependency就把这个类的所有非标记接口都注册成 Scoped。这种做法的好处是零额外概念接口本身就是文档团队里新人也一眼能懂缺点是类上会多一个接口有时候会和领域接口混在一起看着稍微“不干净”。第二种是特性标记[AttributeUsage(AttributeTargets.Class, AllowMultiple false, Inherited true)] public class RegisterAsAttribute : Attribute { public ServiceLifetime Lifetime { get; } public RegisterAsAttribute(ServiceLifetime lifetime) { Lifetime lifetime; } }用法是[RegisterAs(ServiceLifetime.Scoped)] public class UserService : IUserService。特性方式更灵活可以直接在标记时写清楚生命周期还容易加额外参数比如“是否只注册自身”也不污染类的接口列表。缺点是团队里如果有人不知道这个特性存在新写的类忘了标注册器就静默忽略了。我个人对两种方案的态度是小项目、快速原型用特性大项目、约定敏感度高用空接口。原因在于空接口可以通过强制约束来检查——你可以再加一个单元测试扫描所有实现类凡是没有实现任何生命周期标记接口的直接报错这样“忘标”这个问题就变成编译或测试期的问题而不是运行时问题。特性做不到同等强度的检查因为特性是可选添加的。2.3 反射扫描、源生成器、第三方库三条路怎么选自动注入的技术路线有多条差异还挺大反射扫描程序集最简单Assembly.GetTypes()遍历一遍 判断接口组合即可。缺点是有启动性能成本但一般业务项目也就几百个类型完全可忽略。Source Generator源生成器编译期扫描并生成注册代码运行期零反射。适合对启动毫秒级敏感的项目或者需要跨程序集裁剪的场景但实现复杂度明显更高需要写 Generator 并处理增量编译缓存。第三方库如 Scrutor、Autofac 的注册模块。Scrutor 尤其好用它不仅扫描程序集还内置了装饰器模式、策略链的注册支持是省事选项。但引入第三方依赖要团队认可而且它的批量注册约定也需要和自己项目的标记体系配合。我的建议是如果只想解决问题优先考虑 Scrutor如果想加深对容器的理解或者公司不允许随便引包就自己写几十行的反射注册器。这篇文章下面给的就是自己写反射注册器的完整方案因为理解原理之后你用任何第三方库都能更快上手也不怕出了奇怪问题一脸懵。3. 实操从零写一个生命周期自动注入扩展3.1 定义生命周期契约与程序集扫描入口先上我自己常用的这套实现。第一步是定义空标记接口以及一个AddAutoInjection扩展方法的入口。// 生命周期标记接口 public interface ITransientDependency { } public interface IScopedDependency { } public interface ISingletonDependency { } public static class DependencyInjectionExtensions { public static IServiceCollection AddAutoInjection( this IServiceCollection services, params Assembly[] assemblies) { var types assemblies .SelectMany(assembly assembly.GetTypes()) .Where(type type.IsClass !type.IsAbstract !type.IsGenericTypeDefinition) .ToList(); foreach (var type in types) { var lifetime GetLifetime(type); if (lifetime is null) { continue; } RegisterType(services, type, lifetime.Value); } return services; } private static ServiceLifetime? GetLifetime(Type type) { if (typeof(ITransientDependency).IsAssignableFrom(type)) return ServiceLifetime.Transient; if (typeof(IScopedDependency).IsAssignableFrom(type)) return ServiceLifetime.Scoped; if (typeof(ISingletonDependency).IsAssignableFrom(type)) return ServiceLifetime.Singleton; return null; } private static void RegisterType( IServiceCollection services, Type type, ServiceLifetime lifetime) { // 具体注册逻辑见下文 } }这个入口写完之后使用方式非常直观在 Program.cs 里一行搞定builder.Services.AddAutoInjection(typeof(Program).Assembly);如果项目分了多个程序集往里多传几个就行。注意GetTypes()在某些动态加载场景下可能抛ReflectionTypeLoadException稳妥做法是加一个 Try/Catch把能拿到的类型都拿回来private static IEnumerableType SafeGetTypes(Assembly assembly) { try { return assembly.GetTypes(); } catch (ReflectionTypeLoadException ex) { return ex.Types.Where(t t ! null); } }这个防御在插件化框架里基本必备普通单体项目碰到的概率低但写上没坏处。3.2 注册逻辑默认注册接口还是注册自身RegisterType的核心点在于一个类可能实现了多个接口到底把这多个接口都注册到同一个实现还是只注册其中一个主接口我见过的做法有三种只注册类的第一个接口按名称排序或按声明顺序。注册类实现的所有接口除了生命周期标记接口。先注册所有非标记接口再注册自身。从实际项目看方案 2 最实用。因为你把IUserService和IUserRepository都放在一个类上的时候通常希望这两个接口解析到的都是同一个实例哪怕它们在同一个作用域里。方案 3 也有用但有可能导致“按接口拿到的实例”和“按类拿到的实例”是两个不同实例容易让人懵。完整实现我一般这样写private static void RegisterType( IServiceCollection services, Type implementationType, ServiceLifetime lifetime) { var interfaces implementationType.GetInterfaces() .Where(i i ! typeof(ITransientDependency) i ! typeof(IScopedDependency) i ! typeof(ISingletonDependency)) .ToList(); if (interfaces.Count 0) { // 一个接口都没有就注册自身至少保证能 Resolve具体类 services.Add(new ServiceDescriptor( implementationType, implementationType, lifetime)); return; } foreach (var interfaceType in interfaces) { services.Add(new ServiceDescriptor( interfaceType, implementationType, lifetime)); } }很多人可能会问如果多个类实现了同一个接口那后面注册的会覆盖前面的DI 默认取最后一个。这其实是好事因为你可以在不修改原类的情况下通过注册顺序控制“谁才是默认实现”。如果你希望解析出所有实现可以再叠加IEnumerableT的解析方式这是后话。3.3 开放式泛型open generic的特殊处理AddAutoInjection里特意过滤掉了IsGenericTypeDefinition的类型因为开放式泛型的注册方式不同。比如你定义了IEventHandlerT和UserCreatedEventHandler : IEventHandlerUserCreatedEvent这个具体类不是泛型定义会被正常处理。但如果你写的是HandlerBaseT : IHandlerT其中HandlerBaseT本身是泛型定义就需要用AddOpenGenericRegistration。开放式泛型的注册逻辑不难但要注意判断条件private static bool TryRegisterOpenGeneric( IServiceCollection services, Type type, ServiceLifetime lifetime, out bool registered) { registered false; if (!type.IsGenericTypeDefinition) { return false; } var genericInterfaces type.GetInterfaces() .Where(i i.IsGenericType) .Where(i !i.IsGenericTypeDefinition) .ToList(); foreach (var genericInterface in genericInterfaces) { var interfaceDefinition genericInterface.GetGenericTypeDefinition(); services.Add(new ServiceDescriptor( interfaceDefinition, type, lifetime)); registered true; } return registered; }要注意的是serviceType传的是泛型定义而不是封闭泛型类型这样容器在解析IHandlerstring的时候会尝试用HandlerBaseT去匹配Tstring。如果同一个接口泛型定义对应了多个候选实现容器会取最后一个这跟普通类型的规则一致。3.4 用特性标记版本怎么扩展如果团队偏爱特性方案可以在上面的基础上加一个分支。定义好RegisterAsAttribute后在GetLifetime里优先判断特性private static ServiceLifetime? GetLifetime(Type type) { var attribute type.GetCustomAttributeRegisterAsAttribute(); if (attribute ! null) { return attribute.Lifetime; } if (typeof(ITransientDependency).IsAssignableFrom(type)) return ServiceLifetime.Transient; if (typeof(IScopedDependency).IsAssignableFrom(type)) return ServiceLifetime.Scoped; if (typeof(ISingletonDependency).IsAssignableFrom(type)) return ServiceLifetime.Singleton; return null; }这里有个优先级取舍特性优先于标记接口。好处是可以用特性对某个类做定向覆盖坏处是同一个类两套标记并存时容易让人困惑。实际落地时我建议一个项目里只允许一种约定写法要么全用特性要么全用接口混用是维护灾难。3.5 单元测试里验证注册结果写完自动注册扩展我最建议补一个测试用一个测试程序集扫一遍断言“所有标记了生命周期的类都能被正确解析”。测试逻辑大致是[Fact] public void AutoInjection_Should_Register_All_Marked_Types() { var services new ServiceCollection(); services.AddAutoInjection(typeof(MyService).Assembly); var provider services.BuildServiceProvider(); var markedTypes typeof(MyService).Assembly.GetTypes() .Where(t t.IsClass !t.IsAbstract typeof(IHandler).IsAssignableFrom(t) t.GetInterfaces().Any(i i typeof(IScopedDependency) || i typeof(ITransientDependency) || i typeof(ISingletonDependency))); foreach (var type in markedTypes) { var exception Record.Exception(() provider.GetService(type)); Assert.Null(exception); } }这个测试能抓住绝大多数“忘了注册或被过滤规则误伤”的情况。尤其是当自动注入代码改过一次之后跑一下比肉眼核对快得多。4. 实战中踩过的坑与排查记录4.1 Cannot consume scoped service from singleton 的真相这是所有 DI 报错里出现频率最高的一条。报错信息大致是InvalidOperationException: Cannot consume scoped service xxx from singleton yyy.很多新手看到“singleton”就以为是 Singleton 生命周期本身的问题其实根因是注册了 Singleton 的类 A它的构造函数或属性里依赖了一个注册成 Scoped 的类 B。按理说这是设计错误但实际代码里很少直接这么写更多是间接链条ASingleton依赖 CScoped而 C 又依赖 BScoped。排查的时候只看到 A 和 B容易漏掉中间那层。排查方法我建议按三步走看报错堆栈找到真正被解析为 Singleton 的根服务。从根服务的构造函数出发递归检查它所有依赖的注册生命周期。确认链条里有没有 Scoped 被“提前绑定”。修复方式一般有三种把 A 改成 Scoped如果它本来就不该全局共享把 B 改成 Singleton如果 B 本身无状态或者把 B 的解析方式改成IServiceScopeFactory.CreateScope()手动获取。最后一种是万不得已的做法它破坏了容器的统一释放管理必须谨慎用。顺带提一句ValidateScopes只在BuildServiceProvider()之后解析时起作用如果你是用了ServiceProvider的GetService手动解析那校验依然生效但如果你把容器注册完就交给框架比如 ASP.NET Core 的请求管道框架会在每次请求时自动校验所以开发环境一般都能第一时间暴露。4.2 自动注册把不该注册的类也扫进来了反射扫描最尴尬的就是误伤。比如某个类内部有internal的辅助类或者有被Obsolete标记的旧实现如果它恰好继承了某个生命周期标记接口就会被自动注册。这种情况在团队协作里经常发生。我在实际项目里的做法是给扫描器增加过滤规则支持显式排除类型或命名空间private static readonly HashSetType ExcludedTypes new(); public static IServiceCollection AddAutoInjection( this IServiceCollection services, ActionAutoInjectionOptions? configure null, params Assembly[] assemblies) { var options new AutoInjectionOptions(); configure?.Invoke(options); var types assemblies .SelectMany(SafeGetTypes) .Where(type type.IsClass !type.IsAbstract) .Where(type !options.ExcludedTypes.Contains(type)) .Where(type !options.ExcludedNamespaces.Any(ns type.Namespace?.StartsWith(ns, StringComparison.Ordinal) true)) .ToList(); // ... }不过也要小心排除规则别写太多太细否则跟手写注册就没区别了。我的底线是只用命名空间排除比如排除*.Models、*.Dtos、*.Configurations这类明显不可能是服务的类型用类型逐个排除太琐碎。4.3 TryAdd 和 Add 的区别以及多次调用 AddAutoInjection批量注册最怕的一件事services.AddAutoInjection()被调了两次。第一次注册的接口第二次又注册一遍解析的时候默认拿最后一个功能上不会马上炸但会有两个实例被创建如果实现类里有资源清理逻辑就是白白增加对象和内存开销。很多人会用services.TryAddScoped(...)来避免重复注册但注意TryAdd 的“不重复”是以ServiceType为单位的如果第二次注册的是同一个接口它确实不会覆盖。所以一个比较稳的组合是批量注册时用 Add而不是 TryAdd然后保证AddAutoInjection只调用一次。你可以在 Program.cs 里加一行注释“不要重复调用此方法”。如果实在担心重复调用我建议在扩展方法内部用一个HashSetAssembly做去重private static readonly HashSetAssembly _registeredAssemblies new(); public static IServiceCollection AddAutoInjection( this IServiceCollection services, params Assembly[] assemblies) { var newAssemblies assemblies .Where(assembly _registeredAssemblies.Add(assembly)) .ToArray(); if (newAssemblies.Length 0) { return services; } // 继续后续扫描注册 }这个方法能解决“同一个程序集被传了两次”的问题但也带来静态状态测试时要注意重置_registeredAssemblies否则多个测试之间会互相污染。更干净的方案是直接约定“只调用一次”代码里不写状态测试也更省心。4.4 控制台程序、后台任务、单元测试里的生命周期差异很多人以为 DI 只在 Web 项目里能用其实Microsoft.Extensions.DependencyInjection是独立于 ASP.NET Core 的控制台程序照样可以用。但控制台程序里没有“HTTP 请求”这个概念所以 Scoped 生命周期不会自动生效——你需要手动创建 scopeusing var serviceProvider services.BuildServiceProvider(); using var scope serviceProvider.CreateScope(); var userService scope.ServiceProvider.GetRequiredServiceIUserService();在后台任务比如 BackgroundService里同理建议每个任务单元自己创建一个 scope避免一个长生命周期对象里跨多个逻辑单元复用同一个 DbContext。我见过有人图省事在 BackgroundService 构造时注入IServiceScopeFactory然后在ExecuteAsync里循环 inner scope这个模式是对的。单元测试则有个经典坑用BuildServiceProvider()构建出来的 provider 默认ValidateScopes是开启的但如果你在测试里直接GetRequiredServiceIScopedService()没有手动建 scope在某些老版本里会抛异常提示“Cannot resolve scoped service from root provider”。这是因为 root provider 本身被视为一个超长 scope不允许把 Scoped 服务从 root 解析出来。解决办法就是用CreateScope()或建一个假的 scope。4.5 Swagger 页面和 API 前缀的一个联动注意点热词里出现“net core swagger页面api添加统一前缀”这个和 DI 生命周期其实有隐藏关系。设置 Swagger 统一前缀通常你在UseSwagger和UseSwaggerUI中间配置RoutePrefix或者在 Controller 上加[Route(api/[controller])]。但如果你用了某些自动注册的 API 约定比如动态生成 Controller 或动态路由那自动注入的服务可能晚于路由构建生效导致 Swagger 文档里能看到路由但实际访问 404。这里只要记住一点Swagger 元数据的生成时间和服务注册是独立的。Swagger 用的是IApiDescriptionGroupCollectionProvider它在应用启动时根据EndpointDataSource构建。如果你在请求管道里动态注册 Controller那可能需要刷新 Swagger 描述组。不过最常见的场景只是给 API 加统一前缀那就直接在RouteOptions里配置builder.Services.ConfigureRouteOptions(options { options.ConstraintMap.Add(api, typeof(CustomRouteConstraint)); });或者干脆在 Controller 的 Route 属性上写全。这个问题不大但如果你同时做了自动注入又发现 Swagger 里某些接口显示不出来先检查 Controller 是否被 DI 正确解析再检查路由前缀顺序别反了。5. 自动注入体系还能怎么扩展5.1 装饰器模式不修改业务类给服务统一加横切能力自动注入的价值不只在于“少写几行注册代码”它还能给整个服务体系的扩展提供支点。比如我想给所有注册成IScopedDependency的服务自动加上日志或性能监控如果没有自动注入你得在注册时用DecorateTInterface, TDecorator()逐个装饰很累。有了自动注入扫描时可以检测到某个服务是否实现了特定的标记接口然后自动套一层装饰器。Scrutor 对这种支持很好自己写也不复杂你只需要在注册完原始服务后再注册一个装饰器类型把原始服务作为构造函数参数注入。装饰器的生命周期必须和原始服务一致否则可能捕获到错误作用域的对象。5.2 Keyed Services同一个接口注册多个实例.NET 8 开始引入了 Keyed ServicesAddKeyedScoped、AddKeyedSingleton这解决了“一个接口多个实现不同调用方想要不同实现”的经典问题。自动注入里可以约定用特性来指定 keypublic class KeyedServiceAttribute : Attribute { public string Key { get; } public ServiceLifetime Lifetime { get; } public KeyedServiceAttribute(string key, ServiceLifetime lifetime) { Key key; Lifetime lifetime; } }扫描时发现这个特性就调用AddKeyedScoped之类的 API。要注意的是 Keyed Services 的对象解析方式不同[FromKeyedServices(key)]或者GetRequiredKeyedServiceT(key)如果使用方不知道这个 key 的存在很容易拿不到服务然后一脸懵。5.3 和 Source Generator 的对比啥时候该升级反射扫描适合绝大多数项目但它有两个天花板一是启动时反射遍历所有类型有开销虽然通常很小二是无法在编译期发现“接口标记了但程序集加载失败”这类问题。如果项目对启动时间极其敏感比如云函数冷启动或者程序集特别多、类型达到上万可以考虑 Source Generator 方案。Source Generator 的思路是在编译期扫描语法树生成一批ServiceDescriptor的注册代码然后你在 Program.cs 里调用生成的方法。这个方案没有运行时反射启动体积也更小。代价是你要维护一个 Generator 项目要处理生成代码的调试问题也不是所有 DI 容器都兼容。一般业务系统没必要上等真正遇到性能瓶颈再说。最后分享两个我自己的习惯一个是自动注入的代码一定要写在最显眼的位置。我见过太多项目把AddAutoInjection藏在某个 Helper 类的深处新来的同事不知道有这个机制自己手动AddScoped结果同一个接口注册了两次行为变得诡异。保持入口清晰、文档简短比写再牛的反射逻辑都管用。另一个是生命周期标记接口本身也应该是分层约束的。我通常只在应用层Application/Service调用AddAutoInjection基础设施层Infrastructure的手动注册保留在显眼的扩展方法里。这样既享受了批量注册的便利又没有丢掉对特殊注册的控制权。毕竟自动注入是让 80% 的常规服务走流程剩下的 20% 特殊场景还是要人肉把关。