Autofac WithParameter等效.NET Core DI实现及构造参数传递方法

首先对应原Autofac注册的核心行为拆解，无多余配置：

• 生命周期映射：原Autofac 的 InstancePerRequest() 对应内置DI 的 Scoped 生命周期
• 注册范围映射：原 As<ISBOTaskerHelper>() + AsSelf() 表示服务既要支持接口注入，也要支持具体类注入
• 构造函数控制：原 UsingConstructor 强制指定4参数构造函数、WithParameter 传入固定bool值debugMode的行为，通过手动实例化实现完全还原

方案一：完全可控的工厂委托写法（推荐，1:1还原Autofac行为） #

这种方式不存在内置DI自动选错构造函数的问题，和你原来在Autofac里强制指定构造函数的效果完全一致，没有任何不确定性：

// .NET 6+ 顶级语句的Program.cs中配置
builder.Services.AddScoped<ISBOTaskerHelper>(sp =>
{
    // 从容器解析构造函数依赖
    var principal = sp.GetRequiredService<IPrincipal>();
    var portalSettings = sp.GetRequiredService<IPortalSettings>();
    var logger = sp.GetRequiredService<ILogger<SBOTaskerHelper>>();
    // 传入自定义构造参数
    var debugMode = Portal.Site.DebugMode;
    
    // 直接实例化，强制使用指定的4参数构造函数
    return new SBOTaskerHelper(principal, portalSettings, logger, debugMode);
});

// 对应原AsSelf()的注册，支持直接注入SBOTaskerHelper具体类型
builder.Services.AddScoped(sp => sp.GetRequiredService<ISBOTaskerHelper>());

方案二：基于内置DI自动激活的简化写法 #

如果不想手动逐个解析依赖，可以借助ActivatorUtilities实现自动解析剩余依赖，只需要传入自定义的构造参数即可：

builder.Services.AddScoped<ISBOTaskerHelper>(sp =>
{
    // 仅传入自定义的debugMode参数，其余IPrincipal、IPortalSettings、ILogger依赖由容器自动解析
    return ActivatorUtilities.CreateInstance<SBOTaskerHelper>(sp, Portal.Site.DebugMode);
});

// 对应原AsSelf()的注册逻辑
builder.Services.AddScoped(sp => sp.GetRequiredService<ISBOTaskerHelper>());

注意：这种写法依赖内置DI的自动构造函数选择逻辑，如果类存在多个构造函数重载，可能出现选中非预期构造函数的情况，出现这类问题时直接切换到方案一即可。

适配低版本.NET Core的说明 #

如果使用.NET 5及更早版本的Startup.cs结构，上述逻辑只需要原封不动放到ConfigureServices方法中，把builder.Services替换为方法入参的IServiceCollection services即可，核心逻辑完全没有区别。

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