请求先经异常处理、重定向、静态文件等中间件，再依次执行路由、认证、授权，最后进入控制器；响应逆序返回。中间件按注册顺序执行，短路时终止传递，如静态文件或认证失败直接响应。
ASP.NET Core 中间件的执行流程是一个线性的、管道式的处理过程，每个中间件组件都有机会在请求进入和响应返回时进行处理。整个流程围绕一个称为“请求管道（Request Pipeline）”的结构展开。
中间件的基本执行顺序
当一个 HTTP 请求到达应用时，它会依次经过注册在 Program.cs 或 Startup.cs 中的中间件。每个中间件可以选择是否将请求传递给下一个中间件，也可以在请求和响应两个方向上操作。
典型的执行流程如下：
- 请求进入第一个中间件
- 该中间件可以处理请求，然后调用 next() 将控制权交给下一个中间件
- 这个过程一直延续到管道末端（通常是路由匹配并执行控制器或终结点）
- 响应开始回传，再次经过各个中间件（逆序），允许它们在响应阶段添加逻辑
- 最终响应返回客户端
短路请求管道
某些中间件不需要调用 next()，它们可以直接生成响应并终止流程，这被称为“短路”。比如静态文件中间件如果发现请求的是一个存在的 CSS 或 JS 文件，就会直接返回文件内容，不再继续向后传递。
常见用于短路的中间件包括：
- UseStaticFiles：提供静态资源，命中后不继续
- UseAuthentication：验证失败可直接返回 401
- 自定义异常处理中间件：捕获异常后直接返回错误页
中间件的注册顺序至关重要
在 Program.cs 的 UseMiddleware 或专用方法（如 UseRouting、UseAuthorization）中注册的顺序决定了执行顺序。
关键原则：
- UseRouting() 必须在 UseAuthorization() 之前
- 异常处理中间件（如 UseExceptionHandler）通常放在最前面，以便捕获后续中间件抛出的异常
- 终端中间件（如 MVC、MapGet）应放在最后，否则后面的中间件无法执行
典型请求流程示例
以一个常见的 Web API 应用为例：
app.UseExceptionHandler();app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
请求流经顺序为：
- 异常处理器准备就绪（但尚未执行）
- 重定向 HTTP 到 HTTPS
- 尝试提供静态文件
- 路由解析：确定匹配哪个终结点
- 身份验证：检查用户是否登录
- 授权：检查是否有权限访问目标资源
- 执行控制器动作
- 响应按相反顺序返回，各中间件可修改响应头或内容
基本上就这些。中间件的链式结构让开发者能灵活控制请求处理的每一步，只要理解了“先进先出”的执行模型和顺序的重要性，就能合理组织应用逻辑。
