C# 中间件(Middleware)在ASP.NET Core中的作用 - 构建请求处理管道

中间件是ASP.NET Core请求处理的核心，按注册顺序形成链式流水线，通过Use、UseMiddleware和Map方法注册，决定请求的处理逻辑与分支。

中间件是 ASP.NET Core 请求处理管道的核心组件，它像一连串可插拔的“处理单元”，按顺序接收 HTTP 请求、执行逻辑（如验证、日志、身份认证），再决定是否将请求传递给下一个中间件或直接返回响应。

中间件的本质：请求与响应的“流水线工人”

每个中间件本质上是一个委托（RequestDelegate），接收 HttpContext 参数，可读取请求、修改响应，也能选择终止流程或调用 next() 继续向后传递。它不依赖控制器或路由，而是作用于整个应用级别，为所有请求提供统一的横切关注点支持。

注册中间件：Use、UseMiddleware 与 Map 的区别

在 Program.cs 的 WebApplication 实例中，通过不同方法注册中间件，行为各不相同：

• app.Use(...)：添加常规中间件，总是参与每条请求，适合日志、异常处理、CORS 等全局逻辑
• app.UseMiddleware()：显式注册自定义中间件类，适合封装复杂逻辑或需依赖注入的场景
• app.Map("/api", ...)：创建分支管道，仅匹配指定路径前缀的请求才进入该子管道，常用于 API 版本隔离或静态资源分组

执行顺序决定行为——中间件的“前后关系”很关键

中间件注册顺序 = 执行顺序。靠前注册的中间件先收到请求（“上游”），也后收到响应（“下游”）。例如：

• 若把 UseAuthentication() 放在 UseAuthorization() 后面，授权检查会失败——因为用户还没被认证
• 若把 UseExceptionHandler() 放在最后，它就捕获不到前面中间件抛出的异常；必须放在可能出错的中间件之前
• 自定义日志中间件通常放在最前（记录开始）和最后（记录结束），形成“环绕”效果

编写自定义中间件：函数式 vs 类式

两种写法都常见，选型看复杂度：

• 函数式（适合简单逻辑）：
  

  app.Use(async (context, next) => {
    Console.WriteLine("Before request");
    await next();
    Console.WriteLine("After response");
  });

• 类式（推荐用于复用或需构造注入）：
  定义类实现 InvokeAsync(HttpContext context) 方法，通过 services.AddTransient() 注册，再用 UseMiddleware() 启用

基本上就这些。中间件不是黑盒，理解它的链式结构、执行时机和注册位置，就能稳稳掌控整个请求生命周期。