当前位置：首页 > news >正文

Asp.Net Core 请求管道中间件之Middleware

news 2026/5/12 15:20:22

前言

中间件(`Middleware`)

概念

中间件是 ASP.NET Core 请求处理管道（pipeline） 中的一段可插拔组件，接收 HttpContext、执行任意逻辑、并决定是否把请求交给管道中的下一个中间件。管道呈“洋葱模型”（请求顺序进入，响应倒序返回）。

调用签名核心是：RequestDelegate next -> Task Invoke(HttpContext context)。

中间件就是请求管道里的“拦路插件”，每个请求经过它，它可以拦截、修改、放行或终止请求。

1.执行流程

注册顺序决定请求进入的顺序。
每个中间件要决定是否 await next(context)（放行）或不调用 next（短路/终止）。
请求走入时是顺序；响应返回时是逆序（栈式回退）。
每个中间件既可以在请求前处理逻辑，也可以在请求后处理逻辑。

请求 -> Middleware1 -> Middleware2 -> Middleware3 -> Endpoint
响应 <- Middleware3 <- Middleware2 <- Middleware1

2.实现方式

RequestDelegate 是中间件的核心，它接收一个 HttpContext，返回一个 Task。

中间件管道本质上是 RequestDelegate 链。

每个中间件通过调用 await next(context) 来传递请求。

public delegate Task RequestDelegate(HttpContext context);

2.1内联委托方式(`Lambda/RequestDelegate`)

直接在 Configure 中写 Lambda 表达式，RequestDelegate 链的最轻量写法。

特点：

快速、轻量
不可复用
适合简单逻辑、调试或快速原型

app.Use(async (context, next) =>
{Console.WriteLine("请求前逻辑");await next(); // 调用下一个中间件Console.WriteLine("响应后逻辑");
});

示例

在Program中通过委托建立中间件

请求http://localhost:5004/WeatherForecast接口，可以看到中间件执行逻辑

请求前逻辑
执行请求中...
响应后逻辑

2.2类中间件方式(`RequestDelegate+Invoke/InvokeAsync`)

自定义中间件类，通过构造函数注入 RequestDelegate next，实现 InvokeAsync(HttpContext) 方法。

特点：

灵活、可复用
支持依赖注入（构造函数注入服务）
最常用的自定义中间件实现方式

public class CustomMiddleware
{private readonly RequestDelegate _next;public CustomMiddleware(RequestDelegate next){_next = next;}public async Task InvokeAsync(HttpContext context){Console.WriteLine("CustomMiddleware请求前逻辑");await _next(context); // 调用下一个中间件Console.WriteLine("CustomMiddleware响应后逻辑");}
}

调用方式：app.UseMiddleware<MyMiddleware>();

示例

自定义中间件CustomMiddleware

请求接口，可以看到CustomMiddleware请求逻辑

委托中间件请求前逻辑
CustomMiddleware请求前逻辑
执行请求中...
CustomMiddleware响应后逻辑
委托中间件响应后逻辑

2.3接口(`IMiddleware`)

IMiddleware 是 ASP.NET Core 自带的接口化中间件实现方式，通过 DI 容器管理生命周期和依赖，简化传统中间件类的实现。

特点：

生命周期由 DI 管理（Transient/Scoped/Singleton）
不需要手动保存 _next
支持复杂依赖注入，适合大型中间件

public interface IMiddleware
{Task InvokeAsync(HttpContext context, RequestDelegate next);
}public class MyMiddlewareWithDI : IMiddleware
{private readonly ILogger<MyMiddlewareWithDI> _logger;public MyMiddlewareWithDI(ILogger<MyMiddlewareWithDI> logger){_logger = logger;}public async Task InvokeAsync(HttpContext context, RequestDelegate next){_logger.LogInformation("请求前逻辑");await next(context); // 调用下一个中间件_logger.LogInformation("响应后逻辑");}
}

调用方式

// 先注入DI
services.AddTransient<MyMiddlewareWithDI>();
// 再注册中间件
app.UseMiddleware<MyMiddlewareWithDI>();

示例

新增CustomDIMiddleware实现IMiddleware

然后先通过AddTransient<CustomDIMiddleware>()注册到DI，后面再使用UseMiddleware注册中间件CustomDIMiddleware

委托中间件请求前逻辑
CustomMiddleware请求前逻辑
CustomDIMiddleware请求前逻辑
执行请求中...
CustomDIMiddleware响应后逻辑
CustomMiddleware响应后逻辑
委托中间件响应后逻辑

2.4RequestDelegate 工厂方式(高级方式)

将中间件逻辑封装成返回 RequestDelegate 的方法。动态生成中间件、框架内部使用。

特点：

高度灵活、可复用
可动态生成中间件
底层原理仍然是 RequestDelegate 链

public static class CustomMiddlewareFactory
{public static RequestDelegate CreateMiddleware(RequestDelegate next){return async context =>{Console.WriteLine("CustomMiddlewareFactory请求前逻辑");await next(context);Console.WriteLine("CustomMiddlewareFactory响应后逻辑");};}
}

调用方式

app.Use(CustomMiddlewareFactory.CreateMiddleware);

示例

新建自定义中间件工厂(CustomMiddlewareFactory)，然后提供一个创建RequestDelegate的方法

然后使用Use方法调用，Use方法接收一个参数是RequestDelegate并且返回RequestDelegate的委托，其实和委托方式调用蕾西，这里只是封装起来了

委托中间件请求前逻辑
CustomMiddleware请求前逻辑
CustomDIMiddleware请求前逻辑
CustomMiddlewareFactory请求前逻辑
执行请求中...
CustomMiddlewareFactory响应后逻辑
CustomDIMiddleware响应后逻辑
CustomMiddleware响应后逻辑
委托中间件响应后逻辑

2.5内置扩展方法中间件(`Use系列`)

框架自带中间件封装，例如：

// 路由
app.UseRouting();
// 认证
app.UseAuthentication();
// 授权
app.UseAuthorization();
// 执行路由匹配后的请求处理
app.UseEndpoints(endpoints => { ... });

特点：

封装 RequestDelegate 或类中间件
使用方便，集成 MVC / Minimal API
灵活性略低

2.5总结

关于中间件的执行流程，这里调试一遍就很明显了：

中间件按注册顺序依次执行“请求前逻辑”，到达终点后再按相反顺序依次执行“响应后逻辑”，形成典型的洋葱模型（先进后出、后进先出）。

委托中间件请求前逻辑
CustomMiddleware请求前逻辑
CustomDIMiddleware请求前逻辑
CustomMiddlewareFactory请求前逻辑
执行请求中...
CustomMiddlewareFactory响应后逻辑
CustomDIMiddleware响应后逻辑
CustomMiddleware响应后逻辑
委托中间件响应后逻辑

总结

ASP.NET Core 中间件都是 RequestDelegate 链
_next 指向下一个中间件，形成管道链
每个中间件可以在请求前/响应后处理逻辑
不同实现方式只是 封装形式、复用性、DI 生命周期管理 不同

实现方式	核心机制	调用方式	特点
内联委托 / Lambda	RequestDelegate	`app.Use(...)`	快速、轻量，不可复用
类中间件 + Invoke	类 + RequestDelegate	`app.UseMiddleware<T>()`	灵活、可复用，支持依赖注入
实现 IMiddleware 接口	IMiddleware.InvokeAsync	`app.UseMiddleware<T>()` + DI	生命周期可控，支持复杂依赖
RequestDelegate 工厂	返回 RequestDelegate	`app.Use(...)`	高度灵活，可动态生成
内置扩展方法	框架封装 RequestDelegate	`app.UseXxx()`	使用方便，集成 MVC / Minimal API

3.`Use`、`Run`、`Map`、`UseWhen`

Use：标准，多数中间件用 await next() 放行。
Run：终端中间件，不接 next，写完后不会再调用后续中间件（短路）。
Map / MapWhen：基于路径或条件分支路由，创建子管道（可用于多态处理）。
UseWhen：条件中间件，满足条件时在子管道内执行 next，不满足则略过。

方法	是否可放行	作用范围	匹配条件	常见用途
Use	可放行/短路	全局管道	无	日志、认证、异常处理、请求处理
Run	不放行	全局管道/终端	无	健康检查、默认响应、短路请求
Map	可放行/短路	子管道	基于路径	分模块处理不同 URL 分支
UseWhen	可放行/短路	子管道	任意条件	条件化中间件，如仅对 API 或特定 header 生效