.NET Core自带依赖注入为何仍使用Autofac？

虽然.NET Core自带的AddSingleton/AddScoped/AddTransient能满足基础依赖注入需求，但很多项目仍选择Autofac，核心原因如下：

• 高级特性远超自带DI
  自带DI只实现了最基础的构造函数注入，而Autofac能搞定很多复杂场景：

  • 支持属性注入，适配那些没法改构造函数的遗留代码或第三方组件；
  • 可以用命名/键控服务，给同一接口的不同实现打标签，注入时精准挑需要的实例；
  • 能轻松集成动态代理实现AOP，比如统一加日志、事务拦截，自带DI没这原生能力；
  • 支持批量注册，按程序集、命名空间批量扫类型注册，不用挨个写注册代码，省不少事。

• 生命周期管理更灵活
  自带DI只有单例、作用域、瞬时三种生命周期，Autofac能玩出更多花样：

  • 支持自定义生命周期，比如按请求、按嵌套作用域来管理实例；
  • 可以更精细控制对象释放时机，手动处理资源清理逻辑，适合复杂架构。

• 迁移成本低，兼容旧项目
  很多旧.NET项目本来就用Autofac，迁到.NET Core时继续用它，能直接复用原来的DI配置，不用大改代码，减少迁移风险——尤其是大型项目，重构DI的成本太高了。

• 社区生态成熟，扩展性强
  Autofac有大量现成的集成库，能和ASP.NET Core、SignalR、Hangfire这些组件深度整合，解决各种特定场景的问题，而自带DI的生态相对窄很多。

另外，Autofac和ASP.NET Core的集成做得很完善：

它允许开发者用Autofac接管DI容器的同时，保留ASP.NET Core的原生功能。你可以通过AutofacServiceProviderFactory替换默认容器，也能在Startup的ConfigureServices里混合用自带DI方法和Autofac的注册API，不管是逐步迁移还是混合配置都没问题。而且Autofac完全兼容ASP.NET Core的生命周期规则，比如作用域服务会自动和请求绑定，还能叠加自己的自定义规则。

内容的提问来源于stack exchange，提问作者user123456