.NET Core DI下IConfiguration依赖工具类选Static class或Singleton

你倾向的普通类+单例生命周期+构造函数注入方案是完全符合.NET Core生态设计规范的最佳实践，不存在设计合理性问题。

不推荐静态类+方法注入的核心原因 #

• 破坏可测试性：静态类无法被DI容器替换为Mock实现，做单元测试时你只能硬编码传入配置值，无法实现测试用例隔离，后续如果依赖项变多，测试代码的维护成本会极高。
• 维护成本不可控：如果后续工具类新增ILogger、其他服务类依赖，方法注入需要修改所有调用方的传参逻辑，漏改就会触发运行时错误。
• 存在内存泄漏风险：静态类全局持有的特性会绕开DI容器的生命周期管理，如果后续不小心传入Scoped/Transient生命周期的依赖并保存引用，会导致对应对象永远无法被GC回收。

标准实现流程 #

1. 将工具类实现为普通非静态类，通过构造函数显式声明依赖，对传入的依赖做空校验。如果只用到IConfiguration中的特定配置段，更推荐绑定强类型配置后通过IOptions<T>注入，遵循接口隔离原则，避免依赖整个配置根节点：

public class XxxUtility
{
    private readonly IConfiguration _configuration;
    // 更推荐的写法：private readonly XxxSettings _settings;
    public XxxUtility(IConfiguration configuration)
    {
        _configuration = configuration ?? throw new ArgumentNullException(nameof(configuration));
    }

    // 工具方法实现
    public string GetRuntimeConfig()
    {
        return _configuration["XxxConfigKey"];
    }
}

2. 由于是类库项目，不要要求消费方手动注册服务，封装IServiceCollection扩展方法统一完成注册：

public static class ServiceCollectionExtension
{
    public static IServiceCollection AddXxxUtility(this IServiceCollection services)
    {
        // 注册为单例生命周期
        services.AddSingleton<XxxUtility>();
        return services;
    }
}

消费方只需要在启动阶段的ConfigureServices中调用services.AddXxxUtility();即可直接注入使用，不需要感知内部依赖。

静态类的适用边界 #

只有当工具类的方法是完全无状态、无任何外部依赖的纯函数时，才适合实现为静态类，比如通用字符串格式处理、数值类型转换这类和外部配置、服务完全无关的逻辑。只要存在需要从DI容器获取的依赖，就不应该使用静态类。

你产生“本不该遇到这类问题”的困惑是非常正常的：.NET Framework时代没有官方统一的DI容器，开发者普遍习惯用静态类实现工具类；而.NET Core把DI作为核心基础设施，带依赖的工具类走实例注册是标准范式，不属于设计冗余。

内容的提问来源于stack exchange，提问作者Dumitru Laurenţiu