从零构建DI容器：手写简化版IServiceCollection理解.NET Core依赖注入核心机制

花椒哥拜托了

294人浏览 · 2026-02-15 00:28:06

花椒哥拜托了 · 2026-02-15 00:28:06 发布

从零构建DI容器：手写简化版IServiceCollection理解.NET Core依赖注入核心机制

你是否曾在使用 IServiceCollection 的 AddSingleton、AddScoped 或 AddTransient 方法时，好奇过这些简洁的API背后究竟隐藏着怎样的魔法？当我们在ASP.NET Core的 Startup 类中轻松配置服务依赖时，那个看似简单的 ServiceCollection 对象，实际上承载着一套精巧的依赖注入（DI）机制。对于追求技术深度的架构师和高级开发者而言，仅仅停留在API调用层面是远远不够的——理解底层原理，不仅能让你在遇到复杂依赖问题时游刃有余，更能为你定制化DI容器、优化应用架构提供坚实的技术支撑。

今天，我将带你踏上一段逆向工程的旅程，用不到200行C#代码，亲手实现一个简化版的DI容器。我们将从零开始，逐步拆解 ServiceDescriptor 的设计奥秘，剖析构造函数选择的智能算法，并穿插分析ASP.NET Core源码中的关键片段。这不是一次简单的代码仿写，而是一次深入框架核心的探索，旨在让你真正掌握依赖注入的精髓。无论你是想彻底理解.NET Core的DI设计，还是需要为特定场景定制自己的依赖注入方案，这篇文章都将为你提供全新的视角和实用的技术洞察。

1. 依赖注入的本质：从紧耦合到控制反转的演进

在深入代码之前，我们需要重新审视依赖注入的根本价值。很多教程将DI简单描述为“通过构造函数传入依赖”，但这只是表象。依赖注入的核心思想是控制反转——将对象的创建和组装控制权从组件内部转移到外部容器。

想象一下早期的代码编写方式：一个类需要另一个类的实例时，直接在内部使用 new 关键字创建。这种方式带来的直接问题是紧耦合——类A直接依赖于类B的具体实现。当需要替换类B的实现，或者为类B添加测试替身时，你不得不修改类A的源代码。

// 紧耦合的典型示例
public class OrderService
{
    private readonly IEmailSender _emailSender;
    
    public OrderService()
    {
        // 直接依赖具体实现
        _emailSender = new SmtpEmailSender();
    }
    
    public void ProcessOrder(Order order)
    {
        // 处理订单逻辑
        _emailSender.SendConfirmation(order);
    }
}

上述代码中，OrderService 与 SmtpEmailSender 紧密绑定。如果想改用 SendGridEmailSender 或者为单元测试提供 MockEmailSender，都必须修改 OrderService 的构造函数。

依赖注入通过引入抽象层和外部容器，优雅地解决了这个问题：

// 依赖注入改进版
public class OrderService
{
    private readonly IEmailSender _emailSender;
    
    // 依赖通过构造函数注入
    public OrderService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }
    
    public void ProcessOrder(Order order)
    {
        // 处理订单逻辑
        _emailSender.SendConfirmation(order);
    }
}

现在，OrderService 只依赖于 IEmailSender 接口，具体实现由外部决定。这种设计带来了多重好处：

可测试性：可以轻松注入模拟对象进行单元测试
可维护性：实现替换无需修改消费方代码
可扩展性：新功能可以通过新实现无缝集成
关注点分离：每个类专注于自己的核心职责

注意：依赖注入不仅仅是“构造函数注入”这一种形式。虽然.NET Core的默认DI容器主要支持构造函数注入，但其他DI框架（如Autofac）还支持属性注入和方法注入。构造函数注入之所以成为主流，是因为它在对象创建时就明确了所有依赖，避免了部分初始化的问题，同时也更符合不可变对象的设计理念。

2. ServiceDescriptor：DI容器的基本构建块

要理解DI容器的工作原理，首先需要了解其核心数据结构——ServiceDescriptor。在微软的实现中，这个类封装了服务注册的所有关键信息。让我们先看看官方 ServiceDescriptor 的简化结构：

// 微软官方ServiceDescriptor的简化视图
public class ServiceDescriptor
{
    public Type ServiceType { get; }
    public Type ImplementationType { get; }
    public object ImplementationInstance { get; }
    public Func<IServiceProvider, object> ImplementationFactory { get; }
    public ServiceLifetime Lifetime { get; }
    
    // 多个构造函数重载，支持不同的注册方式
    public ServiceDescriptor(Type serviceType, Type implementationType, ServiceLifetime lifetime);
    public ServiceDescriptor(Type serviceType, object instance);
    public ServiceDescriptor(Type serviceType, Func<IServiceProvider, object> factory, ServiceLifetime lifetime);
}

ServiceDescriptor 的设计体现了DI容器的灵活性，它支持三种服务提供方式：

类型映射：指定服务类型和实现类型，容器负责实例化
实例注册：直接提供已创建好的实例（常用于单例）
工厂方法：通过工厂函数动态创建实例

现在，让我们实现自己的简化版 ServiceDescriptor。我们将聚焦于最核心的功能，省略一些边缘情况和优化：

// 自定义简化版ServiceDescriptor
public class MiniServiceDescriptor
{
    public Type ServiceType { get; }
    public Type ImplementationType { get; }
    public object ImplementationInstance { get; }
    public Func<IServiceProvider, object> ImplementationFactory { get; }
    public ServiceLifetime Lifetime { get; }
    
    // 通过实现类型注册
    public MiniServiceDescriptor(Type serviceType, Type implementationType, ServiceLifetime lifetime)
    {
        ServiceType = serviceType ?? throw new ArgumentNullException(nameof(serviceType));
        ImplementationType = implementationType ?? throw new ArgumentNullException(nameof(implementationType));
        Lifetime = lifetime;
    }
    
    // 通过实例注册
    public MiniServiceDescriptor(Type serviceType, object instance)
    {
        ServiceType = serviceType ?? throw new ArgumentNullException(nameof(serviceType));
        ImplementationInstance = instance ?? throw new ArgumentNullException(nameof(instance));
        Lifetime = ServiceLifetime.Singleton;
    }
    
    // 通过工厂方法注册
    public MiniServiceDescriptor(Type serviceType, Func<IServiceProvider, object> factory, ServiceLifetime lifetime)
    {
        ServiceType = serviceType ?? throw new ArgumentNullException(nameof(serviceType));
        ImplementationFactory = factory ?? throw new ArgumentNullException(nameof(factory));
        Lifetime = lifetime;
    }
    
    // 获取服务实例的核心方法
    public object GetInstance(IServiceProvider serviceProvider)
    {
        // 如果已有实例，直接返回
        if (ImplementationInstance != null)
            return ImplementationInstance;
        
        // 如果有工厂方法，使用工厂创建
        if (ImplementationFactory != null)
            return ImplementationFactory(serviceProvider);
        
        // 否则通过反射创建实现类型的实例
        return CreateInstance(ImplementationType, serviceProvider);
    }
    
    private object CreateInstance(Type implementationType, IServiceProvider serviceProvider)
    {
        // 构造函数选择逻辑将在下一节详细实现
        // 这里先返回null作为占位符
        return null;
    }
}

// 服务生命周期枚举
public enum ServiceLifetime
{
    Singleton,
    Scoped,
    Transient
}

我们的 MiniServiceDescriptor 类虽然简化，但已经包含了DI容器的核心逻辑。它能够处理三种不同的注册方式，并通过 GetInstance 方法统一提供实例。注意 CreateInstance 方法目前只是占位符——这正是DI容器最复杂的部分之一，我们将在下一节深入探讨。

为了更清晰地理解三种注册方式的区别，我们通过一个表格来对比它们的特点和适用场景：

注册方式	关键特点	适用场景	性能影响
类型映射	容器负责实例化，支持自动依赖解析	大多数常规服务注册	中等（需要反射和构造函数选择）
实例注册	直接使用现有实例，无创建开销	配置对象、全局单例、第三方库适配	最低（直接返回实例）
工厂方法	完全控制实例创建过程	需要复杂初始化、依赖配置参数、条件创建	可变（取决于工厂逻辑复杂度）

在实际的ASP.NET Core源码中，ServiceDescriptor 的实现还包含了许多优化和边界情况处理，比如对开放泛型的支持、对 IEnumerable<T> 的特殊处理等。我们的简化版本专注于核心概念，为理解原理提供了清晰的切入点。

3. 构造函数选择算法：DI容器的智能核心

当DI容器需要创建一个类型的实例时，它必须决定使用哪个构造函数。这个看似简单的任务，实际上涉及一套精巧的算法。ASP.NET Core的DI容器采用了一种贪婪匹配策略，选择“最具体”的构造函数。

让我们通过一个具体例子来理解这个算法。假设我们有如下服务定义：

public interface IFoo { }
public interface IBar { }
public interface IBaz { }

public class Foo : IFoo { }
public class Bar : IBar { }
public class Baz : IBaz { }

public class ComplexService
{
    public ComplexService(IFoo foo) 
    {
        Console.WriteLine("构造函数1被调用");
    }
    
    public ComplexService(IFoo foo, IBar bar) 
    {
        Console.WriteLine("构造函数2被调用");
    }
    
    public ComplexService(IFoo foo, IBar bar, IBaz baz) 
    {
        Console.WriteLine("构造函数3被调用");
    }
}

现在，我们在容器中注册了 IFoo/Foo 和 IBar/Bar，但没有注册 IBaz/Baz。当我们请求 ComplexService 实例时，容器会如何选择构造函数？

构造函数选择算法的核心规则：

可用性检查：首先排除所有参数无法完全由容器提供的构造函数
贪婪匹配：在可用构造函数中，选择参数最多的那个
唯一性保证：如果多个构造函数参数数量相同，且没有一个是另一个的超集，则抛出异常

根据这些规则，我们分析上面的例子：

构造函数1：参数 IFoo ✓（已注册）
构造函数2：参数 IFoo ✓，IBar ✓（都已注册）
构造函数3：参数 IFoo ✓，IBar ✓，IBaz ✗（未注册）

构造函数3被排除（规则1），在剩下的构造函数1和2中，构造函数2参数更多，因此被选中（规则2）。

现在，让我们实现这个算法。首先，我们需要一个辅助方法来获取构造函数及其参数信息：

// 构造函数选择算法的实现
private object CreateInstance(Type implementationType, IServiceProvider serviceProvider)
{
    var constructors = implementationType.GetConstructors();
    
    // 如果没有公共构造函数，尝试获取非公共构造函数（简化处理）
    if (constructors.Length == 0)
    {
        constructors = implementationType.GetConstructors(
            BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public);
    }
    
    if (constructors.Length == 0)
        throw new InvalidOperationException($"类型 {implementationType.Name} 没有可用的构造函数");
    
    // 评估所有构造函数
    var viableConstructors = new List<ConstructorInfo>();
    
    foreach (var constructor in constructors)
    {
        var parameters = constructor.GetParameters();
        bool allParametersResolvable = true;
        
        foreach (var param in parameters)
        {
            if (serviceProvider.GetService(param.ParameterType) == null)
            {
                allParametersResolvable = false;
                break;
            }
        }
        
        if (allParametersResolvable)
        {
            viableConstructors.Add(constructor);
        }
    }
    
    if (viableConstructors.Count == 0)
    {
        throw new InvalidOperationException(
            $"无法为类型 {implementationType.Name} 解析构造函数。请确保所有依赖都已注册。");
    }
    
    // 选择参数最多的构造函数（贪婪算法）
    var selectedConstructor = viableConstructors
        .OrderByDescending(c => c.GetParameters().Length)
        .First();
    
    // 检查是否存在歧义（多个构造函数参数数量相同）
    var maxParamCount = selectedConstructor.GetParameters().Length;
    var ambiguousConstructors = viableConstructors
        .Where(c => c.GetParameters().Length == maxParamCount)
        .ToList();
    
    if (ambiguousConstructors.Count > 1)
    {
        // 检查是否有一个构造函数的参数是其他的超集
        var supersetConstructor = FindSupersetConstructor(ambiguousConstructors);
        if (supersetConstructor == null)
        {
            throw new InvalidOperationException(
                $"类型 {implementationType.Name} 有多个可用的构造函数，无法自动选择。");
        }
        selectedConstructor = supersetConstructor;
    }
    
    // 解析构造函数参数并创建实例
    var parameterValues = selectedConstructor.GetParameters()
        .Select(p => serviceProvider.GetService(p.ParameterType))
        .ToArray();
    
    return selectedConstructor.Invoke(parameterValues);
}

// 查找参数超集的构造函数
private ConstructorInfo FindSupersetConstructor(List<ConstructorInfo> constructors)
{
    foreach (var ctor in constructors)
    {
        var paramTypes = ctor.GetParameters().Select(p => p.ParameterType).ToHashSet();
        
        bool isSupersetOfAll = true;
        foreach (var otherCtor in constructors)
        {
            if (ctor == otherCtor) continue;
            
            var otherParamTypes = otherCtor.GetParameters()
                .Select(p => p.ParameterType)
                .ToHashSet();
            
            if (!paramTypes.IsSupersetOf(otherParamTypes))
            {
                isSupersetOfAll = false;
                break;
            }
        }
        
        if (isSupersetOfAll)
            return ctor;
    }
    
    return null;
}

这个实现虽然简化，但已经捕捉了ASP.NET Core DI容器构造函数选择算法的精髓。在实际的微软实现中，这个算法还包含更多优化，比如缓存构造函数选择结果以避免重复计算，以及处理泛型类型参数等复杂场景。

提示：构造函数选择算法的一个关键设计决策是优先选择参数最多的构造函数。这个决策基于一个假设：参数更多的构造函数通常提供更完整的初始化。然而，这也意味着如果你的类有多个构造函数，需要仔细考虑它们的参数设计，避免意外的构造函数被选中。

4. 实现MiniServiceCollection：完整的DI容器

有了 MiniServiceDescriptor 和构造函数选择算法，我们现在可以构建完整的DI容器了。我们的目标是实现一个简化版的 IServiceCollection 和 IServiceProvider。

首先，让我们定义容器的接口，模仿微软的设计但保持简洁：

// 服务集合接口
public interface IMiniServiceCollection : IEnumerable<MiniServiceDescriptor>
{
    void Add(MiniServiceDescriptor descriptor);
    IMiniServiceProvider BuildServiceProvider();
}

// 服务提供者接口
public interface IMiniServiceProvider
{
    object GetService(Type serviceType);
    T GetService<T>() where T : class;
}

现在实现 MiniServiceCollection。我们将使用一个列表来存储服务描述符，并实现基本的注册方法：

public class MiniServiceCollection : IMiniServiceCollection
{
    private readonly List<MiniServiceDescriptor> _descriptors = new();
    private readonly Dictionary<Type, MiniServiceDescriptor> _singletonInstances = new();
    private readonly Dictionary<Type, object> _scopedInstances = new();
    
    // 实现IEnumerable接口
    public IEnumerator<MiniServiceDescriptor> GetEnumerator() => _descriptors.GetEnumerator();
    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() => GetEnumerator();
    
    // 添加服务描述符
    public void Add(MiniServiceDescriptor descriptor)
    {
        _descriptors.Add(descriptor);
    }
    
    // 构建服务提供者
    public IMiniServiceProvider BuildServiceProvider()
    {
        return new MiniServiceProvider(
            new List<MiniServiceDescriptor>(_descriptors),
            _singletonInstances,
            new Dictionary<Type, object>()); // 初始为空的作用域实例字典
    }
    
    // 便捷注册方法
    public MiniServiceCollection AddSingleton<TService, TImplementation>()
        where TService : class
        where TImplementation : class, TService
    {
        Add(new MiniServiceDescriptor(typeof(TService), typeof(TImplementation), ServiceLifetime.Singleton));
        return this;
    }
    
    public MiniServiceCollection AddSingleton<TService>(TService instance)
        where TService : class
    {
        Add(new MiniServiceDescriptor(typeof(TService), instance));
        return this;
    }
    
    public MiniServiceCollection AddScoped<TService, TImplementation>()
        where TService : class
        where TImplementation : class, TService
    {
        Add(new MiniServiceDescriptor(typeof(TService), typeof(TImplementation), ServiceLifetime.Scoped));
        return this;
    }
    
    public MiniServiceCollection AddTransient<TService, TImplementation>()
        where TService : class
        where TImplementation : class, TService
    {
        Add(new MiniServiceDescriptor(typeof(TService), typeof(TImplementation), ServiceLifetime.Transient));
        return this;
    }
}

接下来是实现核心的 MiniServiceProvider。这是DI容器的大脑，负责管理服务生命周期和解析依赖：

public class MiniServiceProvider : IMiniServiceProvider
{
    private readonly List<MiniServiceDescriptor> _descriptors;
    private readonly Dictionary<Type, MiniServiceDescriptor> _singletonInstances;
    private readonly Dictionary<Type, object> _scopedInstances;
    private readonly object _syncLock = new();
    
    // 用于检测循环依赖
    private readonly HashSet<Type> _resolvingTypes = new();
    
    public MiniServiceProvider(
        List<MiniServiceDescriptor> descriptors,
        Dictionary<Type, MiniServiceDescriptor> singletonInstances,
        Dictionary<Type, object> scopedInstances)
    {
        _descriptors = descriptors;
        _singletonInstances = singletonInstances;
        _scopedInstances = scopedInstances;
    }
    
    // 根据类型获取服务
    public object GetService(Type serviceType)
    {
        if (serviceType == null)
            throw new ArgumentNullException(nameof(serviceType));
        
        // 检查是否正在解析此类型（循环依赖检测）
        if (_resolvingTypes.Contains(serviceType))
            throw new InvalidOperationException($"检测到循环依赖：{serviceType.Name}");
        
        try
        {
            _resolvingTypes.Add(serviceType);
            
            // 查找匹配的服务描述符
            var descriptor = FindDescriptor(serviceType);
            if (descriptor == null)
            {
                // 对于IEnumerable<T>的特殊处理（简化版）
                if (serviceType.IsGenericType && 
                    serviceType.GetGenericTypeDefinition() == typeof(IEnumerable<>))
                {
                    return HandleEnumerableRequest(serviceType);
                }
                return null;
            }
            
            // 根据生命周期返回实例
            return GetOrCreateInstance(descriptor);
        }
        finally
        {
            _resolvingTypes.Remove(serviceType);
        }
    }
    
    // 泛型版本
    public T GetService<T>() where T : class
    {
        return GetService(typeof(T)) as T;
    }
    
    // 查找服务描述符
    private MiniServiceDescriptor FindDescriptor(Type serviceType)
    {
        // 简化实现：返回最后一个匹配的描述符
        // 实际实现应该支持多个注册和键控服务
        return _descriptors.LastOrDefault(d => d.ServiceType == serviceType);
    }
    
    // 处理IEnumerable<T>请求
    private object HandleEnumerableRequest(Type serviceType)
    {
        var elementType = serviceType.GetGenericArguments()[0];
        var descriptors = _descriptors.Where(d => d.ServiceType == elementType).ToList();
        
        if (descriptors.Count == 0)
            return Array.CreateInstance(elementType, 0);
        
        var instances = new List<object>();
        foreach (var descriptor in descriptors)
        {
            instances.Add(GetOrCreateInstance(descriptor));
        }
        
        var array = Array.CreateInstance(elementType, instances.Count);
        for (int i = 0; i < instances.Count; i++)
        {
            array.SetValue(instances[i], i);
        }
        
        return array;
    }
    
    // 获取或创建实例（处理生命周期）
    private object GetOrCreateInstance(MiniServiceDescriptor descriptor)
    {
        switch (descriptor.Lifetime)
        {
            case ServiceLifetime.Singleton:
                return GetSingletonInstance(descriptor);
                
            case ServiceLifetime.Scoped:
                return GetScopedInstance(descriptor);
                
            case ServiceLifetime.Transient:
                return CreateNewInstance(descriptor);
                
            default:
                throw new ArgumentOutOfRangeException(nameof(descriptor.Lifetime));
        }
    }
    
    // 获取单例实例
    private object GetSingletonInstance(MiniServiceDescriptor descriptor)
    {
        lock (_syncLock)
        {
            if (_singletonInstances.TryGetValue(descriptor.ServiceType, out var existingDescriptor))
            {
                return existingDescriptor.GetInstance(this);
            }
            
            var instance = descriptor.GetInstance(this);
            _singletonInstances[descriptor.ServiceType] = descriptor;
            return instance;
        }
    }
    
    // 获取作用域实例
    private object GetScopedInstance(MiniServiceDescriptor descriptor)
    {
        if (_scopedInstances.TryGetValue(descriptor.ServiceType, out var instance))
            return instance;
        
        instance = descriptor.GetInstance(this);
        _scopedInstances[descriptor.ServiceType] = instance;
        return instance;
    }
    
    // 创建新的瞬时实例
    private object CreateNewInstance(MiniServiceDescriptor descriptor)
    {
        return descriptor.GetInstance(this);
    }
    
    // 创建作用域
    public IMiniServiceProvider CreateScope()
    {
        return new MiniServiceProvider(
            _descriptors,
            _singletonInstances,
            new Dictionary<Type, object>());
    }
}

我们的 MiniServiceProvider 实现了完整的生命周期管理：

单例：在整个应用生命周期内只有一个实例
作用域：在同一作用域内共享实例，不同作用域有不同实例
瞬时：每次请求都创建新实例

容器还实现了基本的循环依赖检测，当检测到A依赖B、B又依赖A的情况时，会抛出异常。这是一个重要的安全特性，防止无限递归。

现在，让我们通过一个完整的示例来测试我们的DI容器：

// 定义一些测试接口和类
public interface ILogger
{
    void Log(string message);
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine($"[LOG] {DateTime.Now:HH:mm:ss}: {message}");
    }
}

public interface IDataService
{
    string GetData();
}

public class DatabaseService : IDataService
{
    private readonly ILogger _logger;
    
    public DatabaseService(ILogger logger)
    {
        _logger = logger;
        _logger.Log("DatabaseService已创建");
    }
    
    public string GetData()
    {
        _logger.Log("从数据库获取数据");
        return "示例数据";
    }
}

public class Application
{
    private readonly IDataService _dataService;
    private readonly ILogger _logger;
    
    public Application(IDataService dataService, ILogger logger)
    {
        _dataService = dataService;
        _logger = logger;
        _logger.Log("Application已创建");
    }
    
    public void Run()
    {
        _logger.Log("应用程序开始运行");
        var data = _dataService.GetData();
        Console.WriteLine($"获取到的数据: {data}");
        _logger.Log("应用程序运行结束");
    }
}

// 使用我们的DI容器
class Program
{
    static void Main()
    {
        var services = new MiniServiceCollection();
        
        // 注册服务
        services.AddSingleton<ILogger, ConsoleLogger>();
        services.AddScoped<IDataService, DatabaseService>();
        services.AddTransient<Application>();
        
        // 构建服务提供者
        var serviceProvider = services.BuildServiceProvider();
        
        // 解析并运行应用
        var app = serviceProvider.GetService<Application>();
        app.Run();
        
        // 演示作用域
        Console.WriteLine("\n--- 演示作用域 ---");
        using (var scope = serviceProvider.CreateScope())
        {
            var scopedApp = scope.GetService<Application>();
            scopedApp.Run();
        }
    }
}

运行这个示例，你会看到依赖注入容器如何自动解析所有依赖，并正确管理服务的生命周期。控制台输出将显示每个服务的创建顺序和日志消息，直观地展示了DI容器的工作流程。

5. 与ASP.NET Core DI容器的对比与扩展思考

我们实现的简化版DI容器虽然功能完整，但与生产级的ASP.NET Core DI容器相比，还有不少差距。理解这些差异，能帮助我们更好地使用官方容器，并在需要时进行扩展。

主要差异对比：

特性	我们的Mini容器	ASP.NET Core DI容器
性能优化	基本实现，无缓存	高度优化，有构造函数缓存、表达式树编译
泛型支持	有限支持	完整支持开放泛型和封闭泛型
服务验证	基本验证	完整的服务验证（ValidateOnBuild）
作用域验证	简单实现	完整的作用域验证（ValidateScopes）
工厂集成	支持基本工厂	支持 `IServiceProvider` 工厂和 `IHttpClientFactory` 等
第三方集成	无	支持Autofac、DryIoc等第三方容器

性能优化示例：ASP.NET Core DI容器使用表达式树编译来避免反射开销

// ASP.NET Core中的优化技术（简化示意）
private Func<IServiceProvider, object> BuildFactory(Type implementationType)
{
    var constructor = SelectConstructor(implementationType);
    var parameters = constructor.GetParameters();
    
    // 创建参数表达式
    var parameterExpressions = parameters.Select(p =>
        Expression.Call(
            Expression.Constant(this),
            nameof(GetService),
            new[] { p.ParameterType }));
    
    // 创建构造函数调用表达式
    var newExpression = Expression.New(constructor, parameterExpressions);
    
    // 编译为委托
    var lambda = Expression.Lambda<Func<IServiceProvider, object>>(
        Expression.Convert(newExpression, typeof(object)),
        Expression.Parameter(typeof(IServiceProvider)));
    
    return lambda.Compile();
}

这种优化将反射开销从每次实例化转移到一次性编译，大幅提升了性能。对于高频创建的服务，这种优化效果显著。

扩展我们的容器：如果需要在实际项目中使用或扩展我们的容器，可以考虑以下方向：

添加键控服务支持：允许同一接口有多个实现，通过键区分
实现装饰器模式：自动包装服务，添加横切关注点
添加配置验证：在构建时检查所有服务是否可解析
支持属性注入：除了构造函数注入，也支持属性注入
集成配置系统：从配置文件自动注册服务

实际应用建议：虽然理解底层原理很重要，但在实际项目中，通常建议使用官方DI容器。它的稳定性、性能和功能完整性都经过了大量生产环境验证。只有在以下情况才考虑自定义或扩展：

需要特殊的生命周期管理策略
有极致的性能要求，且官方容器无法满足
需要与特定框架或库深度集成
作为学习或教学目的

通过这次从零构建DI容器的实践，我们不仅深入理解了依赖注入的核心机制，还掌握了逆向分析框架代码的方法论。这种深度理解使我们能够更自信地使用DI容器，更有效地调试依赖问题，并在必要时进行定制化扩展。记住，优秀的架构师不仅要会使用工具，更要理解工具背后的原理——这样当遇到复杂场景时，你才能做出最合适的技术决策。

亚马逊云科技技术品牌专区

更多推荐