（一）基础部分

中间件是 ASP.NET Core 里处理 HTTP 请求和响应的核心机制，整个程序就是由一串中间件按顺序组成的管道。 请求进来，穿完所有中间件，响应出去。每个中间件是一个加工站。 每启用一个中间件，就是把一段代码插入到管道中，用 app.UseXxx() 的方式添加。 Use 就是往管道里“塞”一个中间件。 注意，usexxx不是自定义名称，而是预写好的方法 举常见的几个： UseRouting() — 匹配URL找到对应的接口 UseAuthentication() — 验证用户身份 UseAuthorization() — 检查用户有没有权限 UseEndpoints() — 执行找到的控制器 都是能点出来的，只要看到知道干什么用就行 中间件管道的执行顺序和 Use 的书写顺序完全一致，从上到下进入，从下到上返回。 先写的先处理请求，后写的先处理响应。 比如这一段： app.UseMiddlewareA(); // 第一步：请求先到A app.UseMiddlewareB(); // 第二步：A放行后请求到B app.UseMiddlewareC(); // 第三步：B放行后请求到C，C处理完返回，响应倒着穿回去 请求路线：A → B → C。响应路线：C → B → A。所以中间件的顺序直接决定了请求的处理流程，写错了顺序可能导致功能异常（比如鉴权写在路由前面）。 中间件的核心是一个 RequestDelegate 类型，名叫 next 的参数，它代表管道里的下一个中间件。 不调用 next()，请求就不往下走。 每一个中间件内部，都能拿到一个委托叫 next。它是一个指向下一个中间件的指针。如果你在自己的中间件里调用了 await next()，就等于把请求交给下一个环节处理。如果你不调用 next()，请求就在这被截停了，后面的中间件全收不到。 来看小练习 下面这段代码，请求能到达控制器吗？ app.Use(async (context, next) => { await context.Response.WriteAsync("到此为止"); }); app.UseRouting(); app.UseEndpoints(...); 答案： 不能 第一个中间件直接返回了响应，没有调用 next()，请求被截停，后面的 UseRouting 和控制器永远收不到。 自己写一个中间件，最快捷的方式是用 app.Use() 直接传入一个匿名方法。 中间件本质上就是一个方法，最简单的写法直接在 Use 里写逻辑。 刚才我们用过的例子，就是一个最基础的自定义中间件： app.Use(async (context, next) => { Console.WriteLine("请求开始"); await next(); // 交给下一个 Console.WriteLine("请求结束"); }); 这种写法适合临时测试或简单逻辑。 正式项目中，中间件通常写成单独的类，配合 UseMiddleware<T>() 或封装成 UseXxx() 扩展方法使用。 把中间件从 Program.cs 里抽出来管理，更有条理。 一个规范的中间件类骨架： public class RequestTimingMiddleware { private readonly RequestDelegate _next; public RequestTimingMiddleware(RequestDelegate next) { _next = next; // 接收下一个中间件 } public async Task InvokeAsync(HttpContext context) { // 请求进来时做的事 await _next(context); // 响应出去时做的事 } } 然后在 Program.cs 里注册： app.UseMiddleware<RequestTimingMiddleware>(); 这样 Program.cs 保持清爽，中间件逻辑可以复用和测试。 好，基础篇已经结束，回顾一下都说了点啥 1. 中间件的定义和工作方式（管道、顺序执行、UseXxx() 注册） 2. 核心机制（next 委托控制请求流动、短路与放行、异步原因） 3. 实现方式（匿名方法快速测试，独立类用于正式项目） 4. 实际应用场景（日志记录、身份校验、异常处理等） 5. 执行的顺序规则（请求正序，响应倒序） OK，恭喜你已经了解了基础，接下来就是前往（二）实战篇了