解析IServiceCollection：服务注册、生命周期与模块化扩展

说到 IServiceCollection，很多人第一反应是“哦，就是 Startup.cs 里那个 builder.Services 嘛”——知道怎么用，但真被问到“它为什么能撑起整个可扩展服务体系”时，又说不清楚。我早几年刚接触 .NET Core 时也是这样，加服务全靠搜代码，AddDbContext、AddSwaggerGen、AddScoped 堆了一长串，看着能跑就行。直到后来接手一个模块特别多的中大型项目，服务注册这块越来越乱，才意识到：IServiceCollection 不是一个“放服务定义的容器”，它是整套依赖注入体系与系统架构之间的接口。理解它的设计意图，才能在项目变大时hold住场面。

这篇文章我把 IServiceCollection 的底层逻辑、注册细节、生命周期陷阱，以及如何基于它做一套可插拔的服务模块，尽量讲透。适合刚接触依赖注入的人，也适合那些已经开始用 IServiceCollection、但想进一步优化服务组织和排查问题的朋友。我会把开发中的实际案例和踩过的一些坑一并放出来，希望对你有用。

1. IServiceCollection 到底是什么，为什么它是可扩展体系的基石

1.1 从一句 builder.Services 说起

用 ASP.NET Core 模板新建项目时，Program.cs 里总会看到这段代码：

csharp复制var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

很多人第一次接触 IServiceCollection，就是从 builder.Services 开始的。在这里，builder.Services 的类型就是 IServiceCollection。它是一个被 .NET 内置依赖注入容器读取的服务描述集合，也就是说，通过 AddControllers()、AddSwaggerGen() 这样一串调用，我们是在往这个集合里“登记”将来可能被容器创建和管理的对象信息。

要理解这个设计，可以拿一家餐厅做类比。IServiceCollection 不是餐桌上的菜，而是厨师手里的菜单：菜单上写清楚有哪些菜、用什么食材、口味是什么，后厨（容器）再根据顾客（应用代码）的点单，把菜品实际做出来。顾客不用知道食材放在哪、怎么做，只需要知道菜名。这里的“菜名”就是接口或抽象类型，“菜品做法”则是服务实现类。

但有一个关键区别需要注意：菜单本身不是菜。IServiceCollection 里存的是服务描述（ServiceDescriptor），并不是服务实例。真正创建实例、管理实例生命周期的，是后面调用 builder.Build() 之后创建的 IServiceProvider。集合负责“登记”，Provider 负责“创建”。这个区分是理解后面一切问题的起点。

1.2 IServiceCollection 的“集合”本质

在早期 .NET Framework 的时代，没有这个概念。我们需要手动管理对象创建，或者在大型项目里引入第三方的 Unity、Autofac、StructureMap 等 IoC 容器。而 .NET Core 架构重构时，微软把依赖注入作为一等公民内置进了框架。IServiceCollection 作为最核心的抽象被定义在 Microsoft.Extensions.DependencyInjection.Abstractions 程序集中。

看一下它的定义，就更能感受到它“就是一个列表”的本质：

csharp复制public interface IServiceCollection : IList<ServiceDescriptor>
{
}

你没看错，它继承的是 IList<ServiceDescriptor>。这意味着我们平常调用 services.AddScoped<IUserService, UserService>()，本质上就是往这个 List 里添加了一个 ServiceDescriptor 对象。ServiceDescriptor 记录着三件最重要的事情：

• 服务类型（ServiceType），通常是一个接口，比如 IUserService；
• 实现类型（ImplementationType），通常是一个具体类，比如 UserService；
• 生命周期（Lifetime），是 Transient、Scoped 还是 Singleton。

既然是 List，那么理论上你完全可以跳过扩展方法，手动去 Add：

csharp复制services.Add(new ServiceDescriptor(typeof(IUserService), typeof(UserService), ServiceLifetime.Scoped));

只是因为框架提供了一系列 AddTransient、AddScoped、AddSingleton 这类语法糖，写起来更简洁。我遇到过一些代码评审场景，新人问“IServiceCollection 是不是不能随意增删服务”，其实可以，它就是普通集合，只要在 Build 之前添加即可。

1.3 它在启动链路中的位置

理清 IServiceCollection 在整个启动链路中的位置，能帮你在出问题时快速定位。典型流程是：

text复制创建 WebApplicationBuilder -> 访问 builder.Services(IServiceCollection) -> 注册服务 -> builder.Build() -> 构建 IServiceProvider -> 从 Provider 中取服务

builder.Build() 一旦执行，IServiceCollection 里的描述就会被快照并用于构建服务容器。在这个时间点之后，集合本身还在，但对它的修改不会再影响已经构建出来的 Provider。所以“注册服务必须在 Build 之前”是一条铁律。

我在 .NET 8 的微服务项目里经常见到一种封装方式：把注册逻辑拆到各个模块的扩展方法中，比如 services.AddOrderModule()、services.AddPaymentModule()，这样 Program.cs 里只保留核心的基础设施注册和模块装配入口。这样做不只是为了好看，更是为了让每个模块的依赖关系内聚到模块自身，主项目不需要关心子模块内部注册了什么。这就是 IServiceCollection 支撑可扩展体系的第一层价值：它提供了一个统一的服务登记入口，入口越规整，体系越容易扩展。

2. 为什么可扩展的服务体系一定需要有容器管理

2.1 控制反转解决的是什么问题

在没有 IoC 容器的时候，如果我们有一个 OrderService 依赖于 IProductRepository 和 IStockService，代码大概率长这样：

csharp复制public class OrderService
{
    private readonly IProductRepository _productRepository;
    private readonly IStockService _stockService;

    public OrderService()
    {
        _productRepository = new SqlServerProductRepository();
        _stockService = new StockService(_productRepository);
    }
}

看起来很直接，问题也不少。核心问题在于：OrderService 不仅要完成自身业务，还得负责创建下游依赖，一旦下游的实现类构造函数发生变化，所有直接或间接 new 过它的地方都得跟着改。而且，如果你想在单元测试里把 IProductRepository 替换成一个内存伪实现，几乎做不到——你被硬编码的 SqlServerProductRepository 卡死了。

控制反转（Inversion of Control，IoC）的核心思想是：把“创建依赖对象”的控制权从调用方手里拿走，交给外层容器。这样 OrderService 只需要声明自己需要什么依赖（构造函数接收 IProductRepository），至于容器给它的到底是 SQL Server 实现还是内存实现，OrderService 并不关心。

2.2 容器带来的三个直接收益

使用 IServiceCollection + IServiceProvider 这套机制后，收益非常直观：

第一，调用方与实现方解耦。Controller 或应用服务只依赖抽象接口，具体实现通过注册中心去替换。在测试中，我们只需要在注册时把 IProductRepository 映射到 InMemoryProductRepository，整个测试替身的问题就解决了。

第二，对象的生命周期被统一管理。谁能活多久、何时被释放，不用程序员在业务代码里手工控制。尤其是数据库上下文、HTTP Client 这类非线程安全的对象，如果生命周期管理错了，很容易出现并发问题或连接泄漏。

第三，对象的组装方式更清晰。构造函数就是依赖清单，通过容器自动装配后，团队看到构造函数就知道该类依赖了哪些外部服务，比任何文档都准确。

我自己的体会是：系统只要稍微复杂一点，比如超过几十个类，没有容器管理的项目维护成本会呈指数上升；而 IServiceCollection 这种内置机制的好处是，它给大家提供了一个统一且最低成本的约束边界。

2.3 集合、描述与容器三者之间的协作

很多资料把 IServiceCollection 直接称为“容器”，这其实有点误导。严格来说，它只是服务描述的集合。真正的容器是 IServiceProvider。两者协作关系可以用一句话概括：IServiceCollection 描述“可以创建什么”，IServiceProvider 负责“实际创建什么”。IServiceProvider 在解析某个类型时，会去查找之前集合里登记的描述，选择匹配的构造函数并递归解析其参数。

这里面有一个细节值得展开：默认的 Microsoft.Extensions.DependencyInjection 容器只支持构造函数注入，不支持属性注入和方法注入。如果你从 Autofac 或其他容器过渡过来，可能需要时间去适应。第三方面向切面的框架（如 Castle DynamicProxy 等）或一些扩展包能弥补这些不足，但绝大多数场景下构造函数注入已经够用。合理利用集合的列表特性，甚至可以做到多个服务共享同一个服务类型，借助 IEnumerable<T> 实现发布订阅或策略编排，这也是后续扩展体系经常使用的一招。

3. 服务注册的核心细节：生命周期、注册方式与批量扫描

3.1 三种生命周期的选择逻辑

这是面试中最常被问、也是实际开发中最容易出错的部分。Transient、Scoped、Singleton 三种生命周期，核心区分点是实例的存活范围。

• Transient（瞬态）：每次从容器中解析时创建一个新实例。适合轻量、无状态的服务，比如工具类、帮助类。优点是永远不会出现状态串扰；缺点也明显，如果对象创建成本高，频繁创建会带来性能开销。
• Scoped（作用域）：同一个作用域范围内共享同一个实例，跨作用域则不同。在 ASP.NET Core 中，一次 HTTP 请求对应一个作用域，所以很适合做数据库上下文（DbContext）、工作单元。它的核心特性是“请求内单例”。
• Singleton（单例）：容器第一次解析时创建一个实例，后续全局复用。适合配置对象、日志器、内存缓存等全局共享且线程安全的服务。

选择生命周期时可以用一个简单标准来判断：服务内部是否包含状态？状态的存活边界应该是什么？如果是无状态的纯函数服务，Transient 和 Singleton 在并发行为上差别不大，但 Singleton 能省去反复创建的开销；如果服务内部使用了 ConcurrentDictionary 做缓存且希望全局共享，就选 Singleton。

如果服务依赖了数据库等作用域服务，那这个服务就不能注册为 Singleton。反过来说，Singleton 可以被 Scoped 服务依赖，Scoped 可以被 Transient 依赖，但方向反了就会出问题。

3.2 注册方式不仅仅是 AddScoped

除了泛型注册方式：

csharp复制services.AddScoped<IProductRepository, SqlServerProductRepository>();
services.AddSingleton<IConfiguration>(configuration);

IServiceCollection 还支持更灵活的非泛型注册，适用于运行时才知道类型，或者同一个接口需要多个实现注册的场景：

csharp复制services.AddScoped(typeof(IProductRepository), typeof(SqlServerProductRepository));
services.AddSingleton(typeof(IPipeline<>), typeof(DefaultPipeline<>));

这个写法配合反射做批量扫描非常关键。因为泛型参数在编译期是写死的，运行时通过程序集扫描拿到一批 Type 时，只能使用非泛型方式注册。

另外还需要了解 TryAdd 系列。AddScoped 的特点是“不管有没有注册过，都会添加”；TryAddScoped 则只在服务未被注册时才添加。这个区别在模块化程序集里特别重要：多个模块可能同时尝试注册同一个基础服务，如果使用 Add，后注册的会覆盖或与先前注册并存，导致行为混乱；使用 TryAdd，可以保证第一次注册生效，避免重复注册带来的不确定性。

3.3 批量注册：扫描程序集自动注册

在实际项目中，最常用的一个封装是“按约定批量注册”。比如我们约定所有应用服务都放在 ApplicationServices 命名空间下，并以 Service 结尾，那么可以写一个扩展方法：

csharp复制public static IServiceCollection AddApplicationServices(this IServiceCollection services, Assembly assembly)
{
    var serviceTypes = assembly.GetTypes()
        .Where(t => t.IsClass && !t.IsAbstract && t.Name.EndsWith("Service"));

    foreach (var type in serviceTypes)
    {
        var interfaces = type.GetInterfaces()
            .Where(i => i.Name == $"I{type.Name}" && i.Assembly == type.Assembly);

        foreach (var serviceInterface in interfaces)
        {
            services.AddScoped(serviceInterface, type);
        }
    }

    return services;
}

可以看到，这里用的是非泛型 AddScoped(Type, Type)，因为编译期不知道类型。批量注册最大的价值是：当项目里新增一个 xxxService 类并让它实现对应接口时，不用再去 Program.cs 里手动加一行注册代码，减少了遗忘的可能。

使用这种约定式扫描时，建议要注意性能边界。大型解决方案如果一次性扫描所有程序集，第一次启动会稍慢，但通常可以接受。如果程序集非常多，可以按模块拆分扫描，或者只扫描业务模块所在程序集，避免把无关程序集全部扫一遍。

4. 实际动手：基于 IServiceCollection 做一套可插拔的模块化服务

4.1 思路：把“服务注册”抽象成模块装配入口

假定现在要设计一个多模块订单系统，包含订单、支付、库存、用户四个模块。我们希望主项目达到什么效果？最好 Program.cs 中只需要明确启用哪些模块，各个模块内部的依赖自己管：

csharp复制var builder = WebApplication.CreateBuilder(args);

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddControllers();

builder.Services.AddOrderModule(builder.Configuration);
builder.Services.AddPaymentModule(builder.Configuration);
builder.Services.AddStockModule();
builder.Services.AddUserModule();

var app = builder.Build();

要达到这个效果，核心做法是：为每个模块定义自己的“注册服务扩展类”，以静态类 + 扩展方法方式，把模块内所有服务注册组织在同一个方法里。这种设计不仅让 Program.cs 清爽，也为后续开启/关闭模块提供了天然位置。

有人会问：为什么用扩展方法而不直接在 Program.cs 里注册？因为 Program.cs 本质上是一个启动入口，不应该承担业务模块的注册细节。把注册逻辑放到模块层，项目结构上就形成了一种“模块自治”的约定：一个模块的 Controller、ApplicationService、Repository、Domain Service，通过模块自己的 AddXxxModule 统一注册，后续维护时打开对应模块的 ServiceCollectionExtensions 就能看到该模块的所有外部依赖与内部服务。

4.2 实现基于配置的注册器

实际项目中，有些服务需要根据配置决定是否注册，有些服务的实现类需要根据环境切换。可以结合 IConfiguration 做条件注册。下面是一个订单模块注册器的示例：

csharp复制public static class OrderModuleServiceCollectionExtensions
{
    public static IServiceCollection AddOrderModule(this IServiceCollection services, IConfiguration configuration)
    {
        // 基础业务服务
        services.AddScoped<IOrderRepository, OrderRepository>();
        services.AddScoped<IOrderService, OrderService>();
        services.AddScoped<IDistributedLockService, RedisDistributedLockService>();

        // 消息事件处理器：支持多实现
        services.AddSingleton<IOrderEventHandler, OrderCreatedEventHandler>();
        services.AddSingleton<IOrderEventHandler, OrderPaidEventHandler>();

        // 通过配置选择不同的实现策略
        var inventoryCheckMode = configuration["Order:InventoryCheckMode"] ?? "Local";
        if (inventoryCheckMode == "Remote")
        {
            services.AddScoped<IInventoryCheckService, RemoteInventoryCheckService>();
        }
        else
        {
            services.AddScoped<IInventoryCheckService, LocalInventoryCheckService>();
        }

        // 用 Options 模式绑定模块配置
        services.Configure<OrderOptions>(configuration.GetSection("Order"));

        return services;
    }
}

这里有几个值得讲的设计点：

第一，IOrderEventHandler 注册了多个实现，解析端可以通过 IEnumerable<IOrderEventHandler> 把所有处理器都取出来执行，形成一种简易的订阅发布模型。IServiceCollection 允许同一个 ServiceType 对应多个 ServiceDescriptor，所以说它本质上是个 List。

第二，通过配置字符串切换实现类，适合策略性差异比较大的场景。如果只是链路中某一个环节不同，更推荐装饰器模式结合自动注册来动态包装，避免 if/else 蔓延。

第三，services.Configure<OrderOptions>(configuration.GetSection("Order")) 是把强类型配置对象注册进容器，之后在任何类中注入 IOptions<OrderOptions> 都能拿到该模块配置。这样模块内部不会散落读取 Configuration 的代码，测试时也能通过替换 Options 来模拟配置。

配置对象与生命周期没有绑定关系，默认情况下 IOptions<T> 按需读取。如果你希望配置在启动后被修改也能动态刷新，可以使用 IOptionsMonitor<T>，它会监听配置变更事件。

4.3 条件注册与多实现切换的进阶做法

上面的 if/else 切换策略虽然直接，但模块多了以后，配置分支会越积越多。我更推荐的方式是：让注册器直接承载多套实现，再依靠选型服务在运行时做解析。

举个例子，库存检查可能有“本地检查”和“远程检查”两种策略，但调用方不希望自己在代码里判断环境。可以把两种实现都注册进容器，然后实现一个策略选择服务：

csharp复制public interface IInventoryCheckServiceFactory
{
    IInventoryCheckService Create(InventoryCheckMode mode);
}

public class InventoryCheckServiceFactory : IInventoryCheckServiceFactory
{
    private readonly IServiceProvider _serviceProvider;

    public InventoryCheckServiceFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public IInventoryCheckService Create(InventoryCheckMode mode)
    {
        return mode switch
        {
            InventoryCheckMode.Remote => _serviceProvider.GetRequiredService<RemoteInventoryCheckService>(),
            InventoryCheckMode.Local => _serviceProvider.GetRequiredService<LocalInventoryCheckService>(),
            _ => throw new NotSupportedException()
        };
    }
}

这里需要注意，手动解析需要同时注册接口和具体类，或者只注册具体类也可以。如果坚持只注册抽象接口，然后在内部通过类型判断后强转，会让容器解析链路变得晦涩，而且破坏了对容器注册内容的可读性。

4.4 模块化时打开或关闭一个模块

模块化不仅仅是代码分层，更可以做到运行时装配。假设整个订单模块在环境变量 FeatureFlags__Order=1 时才启用，Program.cs 可以做以下操作：

csharp复制if (builder.Configuration.GetValue<bool>("FeatureFlags:Order"))
{
    builder.Services.AddOrderModule(builder.Configuration);
}

这样从主项目角度看，订单模块整体成为一个可装卸的部件。对于那些代码量大、业务边界清晰的单体应用来说，这能很大程度缓解代码互相纠缠带来的维护压力。实际上，这就是微服务架构中“服务边界”概念在单体项目里的一种落地形态——先将模块边界通过服务注册收口，后续如果某个模块真正需要拆成独立服务，服务注册层的改动成本会小很多。

5. 典型报错和排查技巧：我从实际项目里遇到的问题

5.1 提示 IServiceCollection 未包含 AddEndpointsApiExplorer 的定义

这几年在 .NET 6 以后写最小 API，或者在类库里做集成服务注册时，最常遇到的错误就是“IServiceCollection 未包含 AddEndpointsApiExplorer 的定义”。第一次碰见这种报错，很多人会以为是代码问题，其实大多数是目标框架或引用程序集的问题。

AddEndpointsApiExplorer 这个方法定义在 Microsoft.Extensions.DependencyInjection.ApiExplorerServiceCollectionExtensions 类中，归属 Microsoft.AspNetCore.Mvc.ApiExplorer 程序集。如果项目本身就是 ASP.NET Core 项目且目标框架支持，理论上可以找到；但普通类库如果没有显式添加 FrameworkReference，连这个方法都不会出现。此外，.NET 5 以下的项目没有内置端点 API 浏览器的概念，自然也无法解析该方法。

我在开发一个可复用服务类库时就碰到过：类库作为独立的类库项目引用了一些 ASP.NET Core 服务，但目标框架只是 netstandard2.0，所以我想在类库里调用 services.AddEndpointsApiExplorer()，编译器直接报错。解决的思路很明确：

• 如果类库依赖的是 ASP.NET Core 相关程序集，需要修改项目文件，加入 <FrameworkReference Include="Microsoft.AspNetCore.App" />；
• 或者目标框架直接使用 net8.0、net9.0，并且让项目类型可引用框架时，再调用该方法；
• 如果只是做纯业务类库，则不建议依赖这个 API。

顺带说一句，现在 .NET 8/9 版本里构建最小 API 的项目模板通常会自动生成该调用，少包、缺引用这类问题使用 SDK 模板就不容易出现。经常遇到这类情况的人，建议做项目模板检查时重点看目标框架和 FrameworkReference。

5.2 循环依赖导致启动崩溃

报错信息往往长这样：A circular dependency was detected for the service of type 'OrderService'。

循环依赖的根本原因是 A 依赖 B，B 又直接或间接依赖 A。容器在解析 A 时发现需要 B，解析 B 时又要求 A，形成了一个无法解开的结构。这类问题的排查思路是：先看构造函数，不要一次注入太多服务；其次思考职责是否划得太粗或太细。

我有一次在重构时把一个模块拆成了 OrderService 和 PaymentService，为了发消息，OrderService 注入了 PaymentService；PaymentService 结算后需要回写订单状态，又注入了 OrderService。设计上这是一个典型的状态流转混乱。正确的做法通常是牺牲一点实时性，引入事件或消息机制，让两个服务在内存总线上通信，而不是彼此直接调用。对于简单的破除循环，还可以使用 Lazy<T> 延迟解析一个依赖，但这是治标不治本，建议只在第三方代码无法修改时考虑。

5.3 把 Scoped 服务注入到 Singleton 服务

很多人会在 Singleton 服务里通过构造函数注入 DbContext 或其它 Scoped 服务，结果运行一段时间后开始报错，或数据表现诡异。原因是 Singleton 在第一次被解析时就要创建实例，而它依赖的 Scoped 服务通常绑定在某个请求作用域内，一个 Singleton 实例的存活期横跨多个请求，根本无法安全持有一个特定请求的 DbContext 实例。

常规做法有三种：

• 将对外暴露的服务注册成 Scoped，而不是 Singleton。这是最省心的做法；
• 在 Singleton 中注入 IServiceScopeFactory，在执行需要作用域服务的逻辑时手动创建新作用域；
• 使用 IDbContextFactory<T>（Entity Framework Core 5.0 之后）来创建隔离的 DbContext 实例。

“把 Singleton 依赖的 Scoped 服务换成工厂”是非常实用的技巧。比如在后台定时任务中调用仓储，可以写成：

csharp复制public class OrderSyncBackgroundService : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public OrderSyncBackgroundService(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            using var scope = _scopeFactory.CreateScope();
            var orderService = scope.ServiceProvider.GetRequiredService<IOrderService>();
            await orderService.SyncAsync();
            await Task.Delay(TimeSpan.FromMinutes(5), stoppingToken);
        }
    }
}

这里的关键在于：不要在构造函数里获取服务，要在执行周期里通过作用域取出服务对象并用完即释放。

5.4 多实现注册后只取到最后一个

有时我们会写：

csharp复制services.AddScoped<IOrderEventHandler, OrderCreatedEventHandler>();
services.AddScoped<IOrderEventHandler, OrderPaidEventHandler>();

然后在构造函数里注入 IOrderEventHandler，期望得到所有的处理器。结果发现实际只会拿到最后一个注册的实例。这是因为容器解析单个服务时，默认行为是返回最后一个注册的服务描述对应的实例。微软官方的文档行为是“多个注册时，最后一次注册优先”。

正确的做法是：启动时注册多个同类型服务给同一个 ServiceType，然后解析端必须使用 IEnumerable<IOrderEventHandler>，或使用不需要提前知道数量的 IServiceProvider.GetServices<T>()。因为 .NET 内置容器会为同一个 ServiceType 维护一个注册列表，解析 GetServices 时才会给你全部实现。

这个坑还是挺隐蔽的，尤其在项目里做事件处理器的开发者越来越多、没有约定统一解析方式时就容易爆发。我建议在模块注册器里明确写出使用多个实现的解析方式，最好是封装一个事件总线，让内部把 GetServices 的逻辑藏好，调用方只发事件，不感知多实现细节。

5.5 服务注册越来越多、启动越来越慢

大型系统里 Program.cs 持续膨胀是必然的，同时容器启动耗时也会被拉长。可以用一个简单的 Stopwatch 在 Build 前后测量，也可以使用 services.Count 来看注册数量级。如果注册数量达到几千条，启动耗时确实可能有百毫秒到一秒的量级。更显著的影响其实来自注册时扫描大量程序集和创建单例实例。

我的经验是：注册服务尽量按模块分组，不要用“扫描全部业务程序集”再逐个反射创建描述，这样扫描范围太大。如果用源生成器，比如 .NET 8 里的 DiSourceGenerator 等社区方案，也能在一定程度上减少反射开销。不过大多数项目远未到要靠这种方式优化的规模，首要的还是保持注册逻辑清晰。

6. 写在最后的经验：从会用 IServiceCollection 到主动设计服务边界

这些年看过的项目越多，越觉得 IServiceCollection 不只是技术组件，它更是一种架构切入点。很多从 .NET Framework 转过来的开发者第一次看到 IServiceCollection 时，会习惯性把它当成一个静态工具类，用完就忘。但真正想把项目做成可扩展的体系，需要在几个层面主动设计：

接口要稳定。IServiceCollection 管理的是服务描述，描述的核心是类型映射。如果项目里大量注册都指向具体类，没有接口抽象，容器管理就失去了解耦意义。约束团队在跨模块引用时尽量依赖接口，是一个优先级很高的规范。

模块要自治。每个业务模块自己编写 AddXxxModule 扩展方法，内部完成注册，避免在 Program.cs 里堆几百行注册代码。当服务边界足够清晰时，后续做服务拆分就有了自然切口。

解析要克制。尽量不要在业务代码里到处注入 IServiceProvider 手动 Resolve 服务，这会让容器变成一个“服务定位器”，让依赖关系变得隐晦。如果确实需要动态选择实现，更推荐定义工厂接口或者策略服务来封装解析逻辑。

生命周期要提前规划。数据库上下文、后台任务、HttpClient、配置对象等高频服务，生命周期选择一旦出错往往要上线后才能发现。建议在注册器的注释里写明“为什么这个服务选 Scoped 而不是 Singleton”，为后来人保留设计决策的上下文。

最后分享一个小技巧：如果你开始接手一个服务注册混乱的老项目，别着急重构所有注册代码。先按模块摸清哪些地方重复注册了同一类型，哪些地方把不同实现注册到了同一个接口下，再针对性收敛。IServiceCollection 的灵活性允许你渐进式地优化，而不是推倒重来。用一套整体可控的注册结构把服务边界立起来之后，后续模块扩展会顺畅很多。