ASP.NET Core 默认 DI 容器不能直接“替换”，只能“接管”
ASP.NET Core 的
IServiceCollection本质是为内置
Microsoft.Extensions.DependencyInjection容器准备的抽象，它不支持运行时切换底层实现。所谓“替换”，实际是在应用启动早期用第三方容器（如 Autofac 或 DryIoc）接管整个服务解析逻辑，并丢弃默认容器实例。
关键点：必须在
Program.cs（.NET 6+）或
Startup.ConfigureServices（.NET 5 及更早）中，**不调用
WebHostBuilder.UseServiceProviderFactory以外的任何构建操作**，否则会触发双重注册或生命周期混乱。
用 Autofac 替换：必须使用 AutofacServiceProviderFactory
Autofac 不提供直接替代
IServiceProvider的方式，而是通过工厂模式注入其容器。常见错误是手动 new
ContainerBuilder后调用
Build()，这会导致 MVC 控制器、中间件等无法被正确解析。 安装
Autofac.Extensions.DependencyInjectionNuGet 包 在
Program.cs中，用
Host.CreateDefaultBuilder().UseServiceProviderFactory(new AutofacServiceProviderFactory())注册逻辑仍写在
ConfigureServices（或
WebApplicationBuilder.Services），但最终由 Autofac 容器承载 若需访问原生 Autofac 功能（如模块、属性注入），需在
ConfigureContainer<containerbuilder>(builder)</containerbuilder>方法中操作
示例片段：
var builder = WebApplication.CreateBuilder(args);
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());
builder.Services.AddControllers();
// ... 其他 AddXxx
// 此方法仅在使用 AutofacServiceProviderFactory 时被调用
builder.Host.ConfigureContainer<ContainerBuilder>(containerBuilder =>
{
containerBuilder.RegisterModule<MyAppModule>();
});
DryIoc 替换更轻量，但要注意 RegisterMany
和作用域行为差异
DryIoc 提供
DryIoc.Microsoft.DependencyInjection包，它实现了
IServiceProviderFactory<icontainer></icontainer>，可直接接入 Host 构建流程。相比 Autofac，它没有“模块”概念，注册更依赖显式
Register或
RegisterMany。 安装
DryIoc.Microsoft.DependencyInjection调用
builder.UseServiceProviderFactory(new DryIocServiceProviderFactory())
RegisterMany默认只注册公开类且忽略接口实现冲突，若需注册所有实现，要加
serviceKey: null或指定策略 DryIoc 默认作用域模型与 MS DI 不完全一致：例如
Scoped在 DryIoc 中对应
Reuse.InWebRequest或
Reuse.InScope，需显式映射 不建议混用
builder.Services注册和
container.Register—— 优先走统一入口（即
ConfigureServices）
替换后调试困难？重点检查 Controller
和 Middleware
的构造函数注入
最常出问题的不是业务服务，而是框架级组件：MVC 控制器、Razor Pages Model、自定义中间件、
IHostedService。它们依赖特定生命周期和元数据（如
[FromServices]、
HttpContext.RequestServices），若容器未正确桥接，会出现
InvalidOperationException: Unable to resolve service或空引用。 确保第三方容器工厂返回的
IServiceProvider支持
GetRequiredService<ihttpcontextaccessor>()</ihttpcontextaccessor>等基础服务 避免在
Configure阶段（即
app.UseXxx）提前解析服务 —— 此时容器可能尚未完成构建 DryIoc 默认不支持
Func<t></t>工厂自动绑定，需手动
Register；Autofac 则默认支持，但需确认是否启用
PropertiesAutowired日志里出现
Cannot resolve scoped service 'X' from root provider，大概率是某个 singleton 类型意外依赖了 scoped 服务，且容器未严格校验作用域层级
真正麻烦的从来不是“怎么换”，而是“换完之后哪些地方悄悄坏了”。尤其当项目已有大量
new ServiceA(new ServiceB())式硬编码，或者用了第三方库自带的 DI 扩展（比如 MediatR 的
AddMediatR），它们对容器实现是有隐式假设的。
