.NET Core中为何内联中间件总会在内置中间件之后执行

这个问题完全源于对ASP.NET Core中间件管道的双阶段执行逻辑的认知偏差，和中间件的注册顺序优先级没有任何关系。

中间件管道的基本执行规则 #

所有按顺序注册的中间件会组成类似洋葱的嵌套结构，整个请求处理流程分为两个独立阶段：

• 入站（请求处理阶段）：严格按照中间件的注册顺序执行，先注册的中间件最先接收到进入管道的请求。只有当中间件执行到await next()语句时，才会把请求传递给管道里下一个注册的中间件。
• 出站（响应返回阶段）：严格按照中间件注册的反向顺序执行，也就是后注册的中间件，对应的出站逻辑会先被触发。这部分逻辑全部书写在中间件代码里的await next()语句之后。

对应代码的实际执行流程 #

给出的内联中间件实现存在一个容易被忽略的关键细节：

app.Use(async (context, next) =>
{
    // 注意：这里await next()之前没有任何自定义代码
    await next();
});

在这个实现里，自定义内联中间件在入站阶段没有任何业务逻辑，执行到await next()就直接把请求转手给了后面注册的UseStaticFiles()中间件。
此时调试过程观察到的流程完全符合管道规则：

1. 请求进入管道，首先触发自定义中间件，但因为入站部分没有可执行的业务代码，执行到await next()就自动跳转到下一个中间件
2. 调试器自然会进入UseStaticFiles()的内部处理逻辑，这也是调试过程中观察到它似乎“抢在前头执行”的直接原因
3. 等UseStaticFiles()完成请求处理、生成响应后，管道会沿嵌套结构反向回溯，才会回到自定义中间件里await next()之后的代码逻辑。

执行顺序的正确验证方式 #

如果需要在静态文件处理前插入自定义逻辑，只需要把对应代码写在await next()之前，就能看到完全匹配注册顺序的执行效果：

app.Use(async (context, next) =>
{
    // 入站逻辑：一定会在UseStaticFiles之前执行
    var beforeStaticFile = DateTime.UtcNow;
    await next();
    // 出站逻辑：会在UseStaticFiles处理完成后执行
    var afterStaticFile = DateTime.UtcNow;
});
app.UseStaticFiles();

这时候在beforeStaticFile这行打断点，一定会比UseStaticFiles的内部代码更早被命中，不存在执行顺序错乱的问题。

内容的提问来源于stack exchange，提问作者bperniciaro