中间件是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 版本隔离或静态资源分组
执行顺序决定行为——中间件的“前后关系”很关键
中间件注册顺序 = 执行顺序。靠前注册的中间件先收到请求（“上游”），也后收到响应（“下游”）。例如：
IBKR Investing with Permission Gate
下载
通过IB网关在Interactive Brokers上投资股票/ETF，使用与okx交易相同的人机确认环节，适用于用户请求检查时
- 若把 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() 注册，再用 UseMiddleware() 启用
基本上就这些。中间件不是黑盒，理解它的链式结构、执行时机和注册位置，就能稳稳掌控整个请求生命周期。
