企业官网建设流程全解析

.NET 默认依赖注入容器：Microsoft.Extensions.DependencyInjection 架构解析与自定义容器集成指南

【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime

导读

Microsoft.Extensions.DependencyInjection是 .NET 官方内置的默认依赖注入（DI）容器实现，它与Microsoft.Extensions.DependencyInjection.Abstractions抽象层组合使用，既可以直接承担应用的注册与解析工作，也可以作为适配桥梁让 Autofac、DryIoc、Grace 等第三方容器接入统一的抽象接口。本文以当前 runtime 仓库中该库的真实源码（src/libraries/Microsoft.Extensions.DependencyInjection）为依据，讲解默认容器的构建流程、服务解析引擎、验证机制与部署方式，并给出使用其他容器替换或增强默认容器的完整路径，帮助你理解 DI 容器的底层原理并在项目中正确选型。

一、默认容器与 Abstractions 抽象层的关系

正如仓库中 README.md 开篇所述：

Microsoft.Extensions.DependencyInjectionis combined with a core DI abstraction underMicrosoft.Extensions.DependencyInjection.Abstractionsthat allows for building different kinds of dependency injection containers to retrieve services from that have been registered with different lifetimes.

这句话揭示了该库的核心设计理念：具体容器实现（Microsoft.Extensions.DependencyInjection）与容器抽象（Microsoft.Extensions.DependencyInjection.Abstractions）是分离的。抽象层定义了IServiceProvider、IServiceCollection、IServiceScope、IServiceScopeFactory、ServiceDescriptor、IServiceProviderIsService、IKeyedServiceProvider等核心契约，而具体容器实现则在抽象之上提供：

• 完整的服务注册与解析能力（支持 Transient / Scoped / Singleton 三种生命周期）；
• 从 .NET 8 起支持键控服务（keyed services），允许按serviceKey解析服务；
• 开箱即用的IServiceProvider实现（ServiceProvider类）与构建扩展方法（BuildServiceProvider）。

这种抽象与实现分离的架构，正是"可以构建不同种类的 DI 容器来检索以不同生命周期注册的服务"的根基：任何符合抽象层契约的容器实现，都可以在保持IServiceProvider使用方式不变的前提下无缝替换默认实现。

二、注册、构建与解析：默认容器的最小使用路径

2.1 构建 ServiceProvider

从IServiceCollection构建出可用的IServiceProvider，核心入口是ServiceCollectionContainerBuilderExtensions中定义的一组扩展方法，见 src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceCollectionContainerBuilderExtensions.cs：

public static ServiceProvider BuildServiceProvider(this IServiceCollection services); public static ServiceProvider BuildServiceProvider(this IServiceCollection services, bool validateScopes); public static ServiceProvider BuildServiceProvider(this IServiceCollection services, ServiceProviderOptions options);

三个重载最终都汇聚到同一个构造函数调用new ServiceProvider(services, options)。其中：

• 无参版本使用静态共享的ServiceProviderOptions.Default实例，避免在默认场景下额外分配对象（源码中internal static readonly ServiceProviderOptions Default = new ServiceProviderOptions();的注释即说明这一优化意图）；
• validateScopes重载等价于传入new ServiceProviderOptions { ValidateScopes = validateScopes }。

一个典型的最小示例：

using Microsoft.Extensions.DependencyInjection; ServiceCollection services = new(); services.AddSingleton<IIdGenerator, GuidIdGenerator>(); services.AddScoped<IUserRepository, UserRepository>(); services.AddTransient<INotifier, EmailNotifier>(); using ServiceProvider provider = services.BuildServiceProvider(new ServiceProviderOptions { ValidateScopes = true, ValidateOnBuild = true, }); IIdGenerator generator = provider.GetRequiredService<IIdGenerator>();

2.2 内置服务的自动注册

在ServiceProvider的构造函数中（src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceProvider.cs），除了用户注册的描述符之外，容器还会无条件注入四类内置服务：

CallSiteFactory同时实现了IServiceProviderIsService与IServiceProviderIsKeyedService，源码注释明确要求这份内置服务清单必须与CallSiteFactory.IsService保持同步，是理解容器"哪些服务永远可用"的关键。

2.3 生命周期与缓存位置的映射

三种生命周期的实现本质上对应CallSiteResultCacheLocation枚举中的缓存位置（见 src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/CallSiteResultCacheLocation.cs）：

• Singleton（Root）：实例缓存在根作用域中，整个容器只创建一次。ServiceProvider.CreateServiceAccessor对Cache.Location == CallSiteResultCacheLocation.Root的调用点做了专门优化，直接通过CallSiteRuntimeResolver.Instance.Resolve(callSite, Root)在首次访问时立即解析并固化结果，之后的每次解析都直接返回已缓存实例；
• Scoped（Scope）：实例缓存在每个ServiceProviderEngineScope的ResolvedServices字典中，同一个作用域内共享，跨作用域各自独立；
• Transient（Dispose/None）：每次解析都新建实例；若实例实现了IDisposable/IAsyncDisposable，会被CaptureDisposable捕获到当前作用域的_disposables列表中，随作用域一起释放。

作用域对象ServiceProviderEngineScope（src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/ServiceProviderEngineScope.cs）同时实现IServiceScope、IServiceProvider、IKeyedServiceProvider、IServiceScopeFactory、IAsyncDisposable，其释放逻辑（Dispose/DisposeAsync）会逆序遍历捕获的可释放服务，并支持同步与异步两种释放路径；对同时通过多个工厂注册解析出的同一共享实例，还会在释放前做引用级去重，保证只释放一次。

三、解析引擎：从解释执行到动态编译的渐进优化

默认容器解析性能的核心秘密在于它的"引擎"设计。ServiceProvider的GetEngine()方法（src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceProvider.cs）根据运行环境选择引擎：

1. 在 .NET Framework 与 .NET Standard 2.0 目标上，或当前运行时支持动态代码编译（RuntimeFeature.IsDynamicCodeCompiled）且未通过 AppContext 开关禁用时，使用DynamicServiceProviderEngine；
2. 在 NativeAOT 等不支持动态代码编译的环境下，退回到RuntimeServiceProviderEngine（src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/RuntimeServiceProviderEngine.cs），采用纯解释方式逐次访问调用点图。

DynamicServiceProviderEngine（src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/DynamicServiceProviderEngine.cs）采用首次解释 + 后台编译替换的策略：

• 服务第一次被解析时，直接走CallSiteRuntimeResolver的解释执行路径，立即返回结果，不阻塞调用方；
• 当同一调用点被解析到第 2 次时（Interlocked.Increment(ref callCount) == 2），通过ThreadPool.UnsafeQueueUserWorkItem在后台线程用CompiledServiceProviderEngine编译出高效的解析委托，随后用ReplaceServiceAccessor原子替换掉旧访问器；
• 后台编译使用UnsafeQueueUserWorkItem刻意不捕获 ExecutionContext，避免不必要的上下文开销；编译失败也会被捕获并记录到事件源，不会影响已返回的正确结果。

编译引擎本身又分为两种实现（二者共同继承ServiceProviderEngine，抽象方法RealizeService定义了解析委托的生产方式，见 src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/ServiceProviderEngine.cs）：

• ExpressionsServiceProviderEngine（ExpressionsServiceProviderEngine.cs）：基于System.Linq.Expressions构造表达式树后编译；
• ILEmitServiceProviderEngine（ILEmitServiceProviderEngine.cs）：直接生成动态 IL 方法，避免表达式树本身的解释开销。

整个过程以CallSiteFactory（src/libraries/Microsoft.Extensions.DependencyInjection/src/ServiceLookup/CallSiteFactory.cs）为核心：它把注册的ServiceDescriptor[]加工成结构化的ServiceCallSite调用点图，缓存到ConcurrentDictionary<ServiceCacheKey, ServiceCallSite>中，并负责检测构造器循环依赖、校验开放泛型注册（例如开放泛型服务必须对应开放泛型实现、实现类型不能是抽象类或接口等规则均在Populate阶段完成）。StackGuard则用于防止极端嵌套解析导致的栈溢出。

四、配置选项：ValidateScopes 与 ValidateOnBuild

默认容器的行为可以通过 ServiceProviderOptions.cs 中的两个开关控制：

两者的典型实践：

ServiceProvider provider = services.BuildServiceProvider(new ServiceProviderOptions { ValidateScopes = true, // 开发环境强烈建议开启，可立即暴露"Scoped 服务从根容器解析"的隐患 ValidateOnBuild = true, // 启动时即验证所有注册可构造，把错误前移到进程启动阶段 });

从源码层面看，ValidateOnBuild的实现位于ServiceProvider构造函数内：逐个调用ValidateService，并捕获每个失败描述符的异常聚合成列表，最终一次性抛出AggregateException；而ValidateScopes对应CallSiteValidator的调用点校验逻辑，属于运行时解析路径上的即时检查。

五、部署方式：OOB（带外）NuGet 包

README.md 的 Deployment 一节明确了该库的部署形态：

Microsoft.Extensions.DependencyInjectionis not included in the shared framework. The package is deployed as out-of-band (OOB) and needs to be installed into projects directly.

也就是说，Microsoft.Extensions.DependencyInjection不属于共享框架（shared framework）的组成部分，而是以带外（out-of-band, OOB）NuGet 包的形式独立发布，使用时必须显式安装到项目中。与之形成对比的是，很多基础库随共享框架提供、无需单独引用。这一特性对实际工程的影响包括：

• 使用默认容器时，需在项目文件中显式添加包引用（版本以 NuGet 上发布的实际版本为准）；
• OOB 的版本节奏独立于 .NET 运行时版本，新特性（例如 .NET 8 引入的键控服务）可以更早地以包形式提供给旧版本运行时使用；
• 在 runtime 仓库中，该库的源码位于 src/libraries/Microsoft.Extensions.DependencyInjection，并带有独立的解决方案文件Microsoft.Extensions.DependencyInjection.slnx，便于按包粒度独立构建与测试。

六、使用其他容器替换或增强默认容器

这是 README 中篇幅最大的主题，也是该库"抽象与实现分离"设计的最直接受益场景。Microsoft.Extensions.DependencyInjection.Abstractions只定义契约，因此任何实现了该契约的第三方容器都可以通过适配层接入，让业务代码继续使用IServiceProvider、IServiceCollection等标准接口，同时获得第三方容器的高级能力（如属性注入、AOP 拦截、更细粒度的生命周期控制等）。

README 列出的主流集成容器包括：Autofac、DryIoc、Grace、Lamar、LightInject、StructureMap、Stashbox、Unity等。在当前 runtime 仓库中，这一兼容性承诺由 tests/DI.External.Tests 测试工程直接验证，该目录下提供了针对 Autofac、DryIoc、Grace、Lamar、LightInject、StashBox 的适配测试文件（Autofac.cs、DryIoc.cs、Grace.cs、Lamar.cs、LightInject.cs、StashBox.cs），并包含一个可跳过的兼容性规范测试基类SkippableDependencyInjectionSpecificationTests——这套测试套件以统一的方式对每个第三方容器运行同一组 DI 规范断言，从而保证"注册的服务能以不同生命周期被正确检索"这一核心行为在任何容器下都不打折扣。

集成第三方容器的通用接入模式大致如下（以实际容器文档为准）：

// 1. 照常使用抽象层注册服务 IServiceCollection services = new ServiceCollection(); services.AddScoped<IMyService, MyService>(); // 2. 通过容器提供的 Populate/适配扩展将 IServiceCollection 的描述符导入第三方容器 // 例如：ContainerBuilder builder = new(); // builder.Populate(services); // 3. 构建出实现 IServiceProvider 的第三方容器实例，交给宿主 // IServiceProvider provider = container.Build();

选择要点：

• 保持宿主兼容：ASP.NET Core 等宿主框架依赖IServiceProvider与IServiceScopeFactory，只要第三方容器正确实现这些契约即可无缝替换；
• 权衡取舍：默认容器在本次仓库源码中已内置"解释执行 + 后台编译"的渐进优化，对绝大多数场景足够高效；第三方容器则适合需要拦截、属性注入等扩展能力的团队；
• 可测试性：可以参考仓库中的 DI.External.Tests 模式，为自己的容器适配层建立规范化的兼容性测试。

七、可观测性：内置的 EventSource 诊断支持

默认容器还内置了基于System.Diagnostics.Tracing.EventSource的诊断能力，实现在 DependencyInjectionEventSource.cs 中：

• EventSource 名称为Microsoft-Extensions-DependencyInjection，采用自描述事件格式（EtwSelfDescribingEventFormat）以保持向后兼容；
• 提供ServiceProviderBuilt、ServiceProviderDisposed、ServiceResolved、CallSiteBuilt、ServiceRealizationFailed、ScopeDisposed等事件，覆盖容器从构建、解析到释放的完整生命周期；
• CallSiteBuilt事件会携带格式化后的调用点树与描述符信息；由于事件源不支持超大载荷，实现中会将大载荷按 10KB 分块（MaxChunkSize）发送；
• 容器内部维护WeakReference<ServiceProvider>列表跟踪活跃提供程序，并有针对性地清理失效引用，避免事件源侧的泄漏。

对生产环境而言，可以通过dotnet-trace等工具订阅该事件源，快速定位"某个服务为何被频繁解析""容器何时被构建/释放"等性能与生命周期问题。

八、贡献标准与成熟度定位

README 的 Contribution Bar 一节说明该库的维护边界：新特性（new features）、新 API、缺陷修复与性能优化均在欢迎之列，对应的主要贡献门槛参见 src/libraries/README.md（该链接在 README 中以../../libraries/README.md#primary-bar形式给出，仓库根视角即为src/libraries/README.md）。同时 README 也明确：该库的 API 与功能已经成熟（mature），但偶尔仍会扩展——这解释了为什么它不常变动，却又不断有键控服务、动态引擎优化等新能力落地。从仓库结构也能看到这一演进的痕迹：ServiceProvider同时支持IServiceProvider与IKeyedServiceProvider，测试工程中包含 KeyedServiceProviderContainerTests.cs 等针对新能力的专项测试。

九、深入阅读指引

若想继续深入，建议按以下路径在仓库中追踪实现：

• 抽象层契约：Microsoft.Extensions.DependencyInjection.Abstractions目录（src/libraries/Microsoft.Extensions.DependencyInjection.Abstractions），定义了IServiceProvider之外的全部注册/解析接口；
• 容器入口： ServiceProvider.cs 与 ServiceCollectionContainerBuilderExtensions.cs；
• 调用点图与校验：ServiceLookup 目录，重点看CallSiteFactory.cs、CallSiteRuntimeResolver.cs、CallSiteValidator.cs与三种引擎实现；
• 生命周期与释放语义：ServiceProviderEngineScope.cs；
• 行为验证测试：tests/DI.Tests（含循环依赖、作用域、键控服务、编译模式等 20 余个测试文件）与 tests/DI.External.Tests（第三方容器兼容性验证）；
• 裁剪（trimming）适配：tests/TrimmingTests 覆盖 AOT/裁剪场景下ActivatorUtilities与注册扩展的正确性。

理解以上路径，即可从"会调用 API"进阶到"读懂容器每次解析背后的调用点构建、缓存决策与引擎切换逻辑"，进而在排障、性能调优和容器选型时做出更专业的判断。

【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime