.NET Framework 4.6.2类库中如何在实例化外访问IServiceCollection/IServiceProvider

首先得明确一点：Microsoft.Extensions.DependencyInjection（简称MS DI）本身并没有内置类似ServiceLocator.Current的全局静态访问机制。这不是疏忽，而是官方的设计理念——MS DI推崇的是依赖注入（DI）模式，而服务定位器（Service Locator）模式会隐藏类的依赖关系，降低代码的可测试性和维护性，所以官方并不鼓励这种做法。

不过在一些老旧项目或者特定场景下，全局访问容器可能是不得不做的选择，下面给你梳理几种可行的方案，以及更优的长期重构思路：

1. 最直接的方案：静态容器类（你提到的方式） #

这是大家最常用的全局访问方式，创建一个静态类来持有IServiceProvider（IServiceCollection一般只在注册阶段用，后续服务获取都靠IServiceProvider）：

public static class AppServiceProvider
{
    private static IServiceProvider _instance;
    private static readonly object _lockObj = new object();

    public static IServiceProvider Instance
    {
        get
        {
            if (_instance == null)
            {
                lock (_lockObj)
                {
                    if (_instance == null)
                    {
                        throw new InvalidOperationException("容器未初始化，请先调用Initialize方法");
                    }
                }
            }
            return _instance;
        }
    }

    public static void Initialize(IServiceProvider serviceProvider)
    {
        lock (_lockObj)
        {
            if (_instance != null)
            {
                throw new InvalidOperationException("容器已初始化，不能重复调用");
            }
            _instance = serviceProvider ?? throw new ArgumentNullException(nameof(serviceProvider));
        }
    }
}

然后在你的启动代码（比如Main方法）里完成初始化：

var services = new ServiceCollection();
// 注册你的各类服务
services.AddTransient<IMyService, MyService>();
services.AddSingleton<IMySingletonService, MySingletonService>();

var provider = services.BuildServiceProvider();
AppServiceProvider.Initialize(provider);

之后在项目的任何地方，你都可以这样获取服务：

var myService = AppServiceProvider.Instance.GetService<IMyService>();
// 或者用GetRequiredService（找不到服务时会抛出异常，更适合确保服务存在的场景）
var singletonService = AppServiceProvider.Instance.GetRequiredService<IMySingletonService>();

这个方案的好处是直观、类型安全，而且通过锁机制保证了线程安全和初始化的唯一性。

2. 不推荐的方案：利用AppDomain存储 #

如果你不想单独写静态类，也可以把IServiceProvider存在AppDomain的全局数据里，但这种方式类型不安全，需要强制转换，而且可读性差，一般不推荐：

// 启动时存储
AppDomain.CurrentDomain.SetData("GlobalServiceProvider", provider);

// 访问时获取
var provider = (IServiceProvider)AppDomain.CurrentDomain.GetData("GlobalServiceProvider");
var myService = provider.GetService<IMyService>();

3. 更优的长期方案：重构为构造函数注入 #

虽然全局访问容器能解决眼前的问题，但从代码质量和可维护性来看，重构代码使用构造函数注入才是最佳实践。这样可以完全避免全局容器的依赖，让类的依赖关系清晰可见，也方便单元测试时注入Mock服务。

举个简单的例子：

// 原来的代码（可能需要全局获取服务）
public class OldBusinessLogic
{
    public void DoWork()
    {
        var myService = AppServiceProvider.Instance.GetService<IMyService>();
        myService.Execute();
    }
}

// 重构后的代码（构造函数注入依赖）
public class NewBusinessLogic
{
    private readonly IMyService _myService;

    public NewBusinessLogic(IMyService myService)
    {
        _myService = myService ?? throw new ArgumentNullException(nameof(myService));
    }

    public void DoWork()
    {
        _myService.Execute();
    }
}

然后在启动代码里，直接从容器解析根服务，依赖链会自动注入：

var businessLogic = provider.GetRequiredService<NewBusinessLogic>();
businessLogic.DoWork();

这种方式下，你完全不需要全局访问容器，代码的可测试性和可读性都会提升很多。

关于IServiceCollection的访问 #

IServiceCollection主要用于服务注册阶段，一般只在启动代码里操作。如果你的类库需要向容器注册服务，更好的方式是提供扩展方法，让启动代码主动调用，而不是全局暴露IServiceCollection：

public static class MyLibraryServiceExtensions
{
    public static IServiceCollection AddMyLibraryServices(this IServiceCollection services)
    {
        // 注册类库内部的服务
        services.AddTransient<IMyLibraryService, MyLibraryService>();
        return services;
    }
}

然后在Main里这样使用：

services.AddMyLibraryServices();

这完全符合MS DI的设计模式，也避免了全局状态的问题。

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