ASP.NET Core中为何部分中间件需ConfigureServices注册部分无需

核心实现差异 #

两类中间件的实例化逻辑、生命周期、依赖注入规则完全不同，直接导致了注册要求的区别：

• 实例化逻辑差异
  • 约定式中间件（即示例中RequestMiddleware这类不实现IMiddleware的中间件）：实例由框架在应用启动构建请求管道时通过反射直接创建，整个应用生命周期内全局只有一个单例实例，全程不走DI容器解析类型。构造函数仅要求传入固定的RequestDelegate参数，其余依赖不会在构造阶段注入。
  • 实现IMiddleware接口的中间件：实例由DI容器负责创建，框架每次处理请求时都会根据你注册的服务生命周期，从DI容器中解析对应实例，不会自行通过反射创建对象。
• 依赖注入规则差异
  • 约定式中间件支持方法注入：InvokeAsync方法里除了固定的HttpContext参数，你可以直接添加任意其他依赖参数，框架会在每次请求进入中间件时，从当前请求作用域的DI容器中解析这些参数传给方法。因为构造实例时不需要DI容器参与，自然不需要提前把中间件类型注册到DI。

    注意：约定式中间件是全局单例，绝对不要在构造函数里注入Scoped生命周期的服务（比如EF Core的DbContext），否则会出现依赖逃逸问题：Scoped服务会被单例中间件持有，不会随请求结束释放，后续所有请求都会复用同一个Scoped实例，直接导致数据错乱、内存泄漏等问题。需要使用Scoped服务时，必须把依赖放到InvokeAsync方法的参数列表里做方法注入。

  • IMiddleware实现类不支持方法注入：InvokeAsync方法只允许传入固定的HttpContext和RequestDelegate两个参数，所有依赖都必须通过构造函数注入，而构造注入的前提是DI容器中已经注册了这个中间件类型，否则容器无法完成实例构建，运行时会直接抛出异常。
• 生命周期差异
  • 约定式中间件生命周期固定为单例，和应用程序生命周期一致。
  • IMiddleware实现类的生命周期完全由你在ConfigureServices中的注册规则决定，官方推荐使用AddTransient注册，保证每个请求拿到独立的中间件实例，这种模式下你可以放心在构造函数中注入Scoped生命周期的服务，不会出现生命周期异常。

UseMiddleware<T> 内部的判断逻辑 #

你调用app.UseMiddleware<T>()时，框架内部会做类型判断走两个完全不同的分支：

1. 如果类型实现了IMiddleware接口，执行逻辑为：
   每次请求到达该中间件时，调用IServiceProvider.GetRequiredService<T>()从DI容器获取实例，再调用实例的InvokeAsync方法。如果DI中没有注册该类型，直接抛出InvalidOperationException。
2. 如果类型是约定式中间件，执行逻辑为：
   启动时通过ActivatorUtilities.CreateInstance直接反射创建单例实例，把下一个中间件的RequestDelegate传入构造函数；每次请求时解析InvokeAsync方法的参数列表，从当前请求上下文的DI中获取对应参数传入，执行方法逻辑。整个过程不需要你提前在DI中注册中间件类型。

注：你给出的IMiddleware示例代码存在笔误，定义的类名是SampleMiddleware，注册和调用时写的是AppSampleLogsMiddleware，实际使用时需要保证类名一致。

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