ASP.NET Core中的依赖注入(DI)是否会带来性能开销？

DI的性能开销说明 #

现代主流DI容器的单例注入开销完全在微秒级，远达不到你担心的毫秒级响应损耗，绝大多数性能敏感的生产场景都可以直接使用，不需要担心性能问题：

• 单例服务仅在应用启动时完成一次实例化，后续注入过程仅传递已有对象的引用，执行开销可以忽略不计
• 若你不信任第三方DI容器的性能，还可以手动实现极简的依赖解析逻辑：只需要用静态字段保存接口实例，启动时赋值为生产环境实现，测试环境赋值为stub，运行时调用的开销和原有的静态类调用完全一致，没有任何额外损耗。

无需引入DI的可测试性优化方案 #

如果你确定不想使用任何DI相关的实现，以下几种方案可以在完全不损失性能的前提下解决静态类无法注入存根的问题：

• 静态类预留测试替换入口
  给现有的静态类增加对应的接口抽象，内部持有一个静态的接口实例字段，生产环境默认赋值为真实实现，额外提供一个仅测试环境使用的静态方法用来替换该实例，生产环境的调用逻辑完全不受影响，性能和原有实现一致。
  示例代码如下：

public interface IMyService
{
    int GetBusinessValue();
}

// 原有静态服务类改造后
public static class StaticMyService
{
    private static readonly IMyService _realImpl = new MyServiceImpl();
    private static IMyService _currentImpl = _realImpl;

    // 仅单元测试时调用该方法替换存根
    public static void SetTestStub(IMyService stub)
    {
        _currentImpl = stub ?? _realImpl;
    }

    // 原有公开方法保持不变
    public static int GetBusinessValue() => _currentImpl.GetBusinessValue();
}

• 条件编译拆分实现
  通过编译指令区分生产和测试构建，生产构建时直接编译为静态调用，测试构建时走可注入逻辑，完全不会在生产环境引入任何额外的运行时开销。
• Ambient Context模式
  针对全局公共服务，通过环境上下文的全局静态字段保存服务实例，生产环境默认初始化为真实单例，测试运行前替换为存根实现，调用开销同样可以忽略。

提示：所谓DI会带来显著性能损耗的认知大多是针对多年前未做优化的老旧容器，现有主流框架内置的DI实现针对高频调用场景已经做了极致优化，完全没有必要为了感知不到的性能损耗牺牲代码的可维护性和可测试性。

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