C# IOC容器有哪些？主流依赖注入容器全面对比与选型指南

控制反转（IoC，Inversion of Control）是面向对象编程中一种重要的解耦思想，它的核心做法是把对象的创建和依赖管理交给外部容器，而不是在类内部通过new来硬编码。C#生态经过多年发展，涌现出了一批成熟的IOC容器，从微软官方的Microsoft.Extensions.DependencyInjection到第三方阵营的Autofac、Ninject、DryIoc等，各有各的定位。本文就来盘点这些主流容器，看看它们分别适合什么样的场景。

一、微软官方容器：Microsoft.Extensions.DependencyInjection

这是目前.NET生态的默认选择，ASP.NET Core整个框架就是构建在它之上的。它的设计哲学是轻量加快速，牺牲了一部分高级特性换来极小的开销和极快的解析速度。对于绝大多数业务系统来说，它提供的三种生命周期已经够用了。

它支持三种生命周期：Transient（每次解析都创建新实例）、Scoped（在同一个作用域内共享实例，常用于一次HTTP请求）、Singleton（全局单例）。通过IServiceCollection注册服务，再从IServiceProvider解析，整个流程非常直观。

var services = new ServiceCollection();
// 注册服务与实现
services.AddTransient<IOrderService, OrderService>();
services.AddScoped<IUserRepository, UserRepository>();
services.AddSingleton<ICacheManager, CacheManager>();

var provider = services.BuildServiceProvider();
var orderService = provider.GetRequiredService<IOrderService>();

它的局限也比较明显：原生不支持属性注入和拦截器（AOP），泛型注册的灵活性不如Autofac。不过这些能力可以通过Scrutor等扩展库补齐，社区里也提供了AutofacExtensions来直接替换底层容器。

二、功能全面的代表：Autofac

Autofac是.NET世界中最受欢迎的第三方容器，功能丰富度几乎是天花板级别。它支持构造函数注入、属性注入、拦截器（配合Castle.DynamicProxy实现AOP）、模块化注册、命名服务等高级特性，在大型项目、遗留系统改造中特别受欢迎。

Autofac的模块机制允许你把不同业务领域的注册逻辑拆分到独立的Module类中，随着项目膨胀也能保持注册代码的整洁。它对装配扫描的支持也很强，可以按约定批量注册，比如扫描某个程序集里所有实现了仓储接口的类。

var builder = new ContainerBuilder();
builder.RegisterType<OrderService>().As<IOrderService>().InstancePerLifetimeScope();
builder.RegisterType<UserRepository>().As<IUserRepository>().SingleInstance();

// 模块化注册
builder.RegisterModule<BusinessModule>();

// 接入ASP.NET Core时替换默认容器
builder.Populate(services);
var container = builder.Build();

在ASP.NET Core项目中使用Autofac也很方便，通过UseAutofac扩展方法即可完成替换。需要注意的是，Autofac的作用域模型和微软容器略有差异，InstancePerLifetimeScope对应微软的Scoped，但嵌套作用域的行为需要留意，避免误把Scoped服务注册成单例导致数据错乱。

三、轻量与性能路线：Ninject、DryIoc和Lamar

Ninject曾经非常流行，语法友好、上手门槛低，通过Bind和To就能完成注册，非常适合中小型项目和学习用途。不过它的解析性能在主流容器中偏弱，且社区活跃度近年下滑明显，新项目选型时要慎重。

var kernel = new StandardKernel();
kernel.Bind<IOrderService>().To<OrderService>().InTransientScope();
kernel.Bind<IUserRepository>().To<UserRepository>().InSingletonScope();

var service = kernel.Get<IOrderService>();

DryIoc是性能党的心头好，它的解析速度和内存占用在各类基准测试中常年名列前茅，同时功能并不缩水，支持拦截器、装饰器、开放泛型等特性。如果你在做高并发的服务，比如网关、实时消息处理，DryIoc值得认真考虑。

Lamar是老牌容器StructureMap的继任者，由MartAdmin框架作者维护，主打快速启动和ASP.NET Core深度集成，同时兼容StructureMap的大部分API，方便老项目平滑迁移。

四、经典老将：Unity以及如何选型

Unity是微软企业库时代的产物，曾经在企业开发中占有大量份额。但微软官方已将其移交社区，后续维护基本停滞，新项目不建议再选它，除非是在维护存量代码。类似的还有StructureMap，它已正式宣布废弃，作者建议迁移到Lamar。

选型建议其实很简单：如果是普通的ASP.NET Core或Worker Service项目，直接用官方容器，没必要额外引入依赖；当官方容器的能力确实不够，比如需要属性注入、AOP拦截、复杂的模块化注册时，再升级到Autofac；对性能有极致要求就选DryIoc。切记不要为了炫技引入重量级容器，容器本身只是工具，保持团队使用习惯统一、注册代码可读，比选哪个容器更重要。

C# IOC容器依赖注入DI框架修改时间：2026-09-05 19:08:45