中间件是 ASP.NET Core 请求处理管道的核心组件,它像一连串可插拔的“处理单元”,按顺序接收 HTTP 请求、执行逻辑(如验证、日志、身份认证),再决定是否将请求传递给下一个中间件或直接返回响应。
中间件的本质:请求与响应的“流水线工人”
每个中间件本质上是一个委托(RequestDelegate),接收 HttpContext 参数,可读取请求、修改响应,也能选择终止流程或调用 next() 继续向后传递。它不依赖控制器或路由,而是作用于整个应用级别,为所有请求提供统一的横切关注点支持。
注册中间件:Use、UseMiddleware 与 Map 的区别
在 Program.cs 的 WebApplication 实例中,通过不同方法注册中间件,行为各不相同:
app.Use(...):添加常规中间件,总是参与每条请求,适合日志、异常处理、CORS 等全局逻辑 app.UseMiddleware执行顺序决定行为——中间件的“前后关系”很关键
中间件注册顺序 = 执行顺序。靠前注册的中间件先收到请求(“上游”),也后收到响应(“下游”)。例如:
若把 UseAuthentication() 放在 UseAuthorization() 后面,授权检查会失败——因为用户还没被认证 若把 UseExceptionHandler() 放在最后,它就捕获不到前面中间件抛出的异常;必须放在可能出错的中间件之前 自定义日志中间件通常放在最前(记录开始)和最后(记录结束),形成“环绕”效果编写自定义中间件:函数式 vs 类式
两种写法都常见,选型看复杂度:
函数式(适合简单逻辑):app.Use(async (context, next) => {<br> Console.WriteLine("Before request");<br> await next();<br> Console.WriteLine("After response");<br>});
类式(推荐用于复用或需构造注入):定义类实现 InvokeAsync(HttpContext context) 方法,通过 services.AddTransient
基本上就这些。中间件不是黑盒,理解它的链式结构、执行时机和注册位置,就能稳稳掌控整个请求生命周期。
