如何让业务类无需手动传参即可访问DI容器IServiceProvider

静态全局_globalServiceProvider方案确实不可取，一方面无法正确获取请求生命周期内的Scoped服务（比如DbContext、当前用户上下文等），会引发线程安全、资源泄漏等问题，另一方面完全违背DI显式依赖的设计原则，后期维护和单元测试难度极高。

针对你的场景，推荐以下两种经过生产验证的方案：

1. 优先推荐：基于IHttpContextAccessor的请求上下文服务定位器 #

适合所有业务逻辑均由HTTP请求触发的场景，是微软官方支持的兼容方案：

实现步骤 #

1. 首先在服务注册阶段添加IHttpContextAccessor的注册：

// Startup.cs ConfigureServices 或 Program.cs
services.AddHttpContextAccessor();

2. 封装静态服务定位器，从当前请求上下文获取Scoped服务提供者：

public static class RequestServiceLocator
{
    private static IHttpContextAccessor _accessor;

    // 应用启动时仅需调用一次完成初始化
    public static void Initialize(IHttpContextAccessor accessor)
    {
        _accessor = accessor ?? throw new ArgumentNullException(nameof(accessor));
    }

    // 业务代码直接调用该方法获取服务
    public static T GetRequiredService<T>()
    {
        var httpContext = _accessor.HttpContext;
        if (httpContext == null)
        {
            throw new InvalidOperationException("当前调用不在HTTP请求上下文中，无法获取请求范围服务");
        }
        return httpContext.RequestServices.GetRequiredService<T>();
    }
}

3. 应用启动时完成初始化：

// Program.cs 构建完WebApplication后调用
var app = builder.Build();
RequestServiceLocator.Initialize(app.Services.GetRequiredService<IHttpContextAccessor>());

效果 #

所有处于请求处理链路中的业务对象，无需逐层传递IServiceProvider，直接调用RequestServiceLocator.GetRequiredService<目标服务>()即可获取对应服务，且自动适配当前请求的服务生命周期。

2. 兼容非HTTP场景：基于AsyncLocal的环境上下文服务定位器 #

如果你的业务逻辑还会被后台任务、定时任务等非HTTP请求触发，可以用AsyncLocal存储当前异步上下文的服务提供者：

实现代码 #

public static class AmbientServiceLocator
{
    private static readonly AsyncLocal<IServiceProvider> _currentProvider = new();

    // 作用域入口处赋值
    public static void SetCurrentProvider(IServiceProvider provider)
    {
        _currentProvider.Value = provider ?? throw new ArgumentNullException(nameof(provider));
    }

    // 业务代码调用获取服务
    public static T GetRequiredService<T>()
    {
        var provider = _currentProvider.Value;
        if (provider == null)
        {
            throw new InvalidOperationException("当前异步上下文未设置服务提供者");
        }
        return provider.GetRequiredService<T>();
    }
}

使用方式 #

• HTTP请求场景：在全局ActionFilter或者控制器基类中，请求进入时调用AmbientServiceLocator.SetCurrentProvider(HttpContext.RequestServices)
• 后台任务场景：创建Scoped作用域时，调用AmbientServiceLocator.SetCurrentProvider(scope.ServiceProvider)
  所有同一异步上下文内的代码都可以直接获取到正确的服务，无需逐层传递。

注意事项 #

• 以上两种方案属于服务定位器模式，不属于纯DI的最佳实践，仅推荐用于现有项目改造，解决手动传递IServiceProvider的冗余问题
• 新开发的业务代码仍推荐优先使用构造函数注入显式声明依赖，更易测试和维护
• 不要在单例服务中调用上述定位器获取Scoped服务，会触发上下文不存在的异常

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