.NET Minimal API中间件短路返回是否为不良代码模式？

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapPost("/name", (string? name) => Results.Ok($"From endpoint: {name}")
   .AddEndpointFilter<NameEndpointFilter>();

app.Run();

public class NameEndpointFilter : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(
        EndpointFilterInvocationContext context,
        EndpointFilterDelegate next
    )
    {
        if (context.HttpContext.GetRouteValue("name") is string name)
        {
            return Results.Problem($"From filter: {name}");
        }

        return await next(context);
    }
}

1. 是否有其他开发者反感该模式？ #

肯定有。不少开发者觉得这种短路逻辑会打破请求处理的线性流程，尤其是多个Filter叠加时，调试得来回查找哪一步触发了短路，远不如把校验逻辑直接写在端点里直观。还有人担心这种模式被滥用，导致Filter里塞满业务逻辑，端点本身沦为空壳，后期维护找不到核心逻辑的位置。

2. 多数教程为何采用类似模式？ #

• 演示直观：教程需要快速展示Filter的核心能力——拦截请求、提前响应，短路逻辑用最少的代码就能让学习者快速理解“Filter可以在端点执行前直接返回结果”。
• 贴合框架设计：ASP.NET Core本身基于中间件管道设计，Filter作为端点级中间件，短路是中间件的常规用法之一，教程会顺着框架的设计思路讲解。
• 简化示例：如果展示完整的“Filter处理后放行到端点”流程，需要更多代码支撑前后逻辑，短路模式用极简代码就能讲清核心功能，适合入门教学场景。

3. 该模式相比其他方案有何优势？ #

• 逻辑复用：多个端点需要相同的校验、前置处理时，把短路逻辑写在Filter里，不用在每个端点重复编码，符合DRY原则。比如多接口的权限校验，一个Filter就能覆盖所有场景。
• 关注点分离：把校验、日志、异常处理这类横切逻辑从端点业务代码中抽离，端点只专注核心业务，代码结构更清晰。
• 流程控制灵活：支持多Filter按顺序叠加，短路逻辑能在任意阶段终止请求，比在端点里写条件判断更灵活——比如先做权限校验，再做参数校验，任意一步不通过直接返回。

4. 将其类比为GOTO是否有误？ #

确实有问题。GOTO是无规则的任意跳转，会彻底打乱代码流程，难以追踪；而Filter的短路是管道模型中的可控终止：

• Filter按预设顺序执行，每个Filter的位置明确，短路是主动终止后续管道流程，整体流程可预测。
• GOTO能跳转到任意标签，完全破坏代码结构；Filter短路只是停止执行后续Filter和端点，仍遵循管道的线性结构，只是提前退出。

简单来说，GOTO是“乱跳”，Filter短路是“提前结束流程”，二者本质逻辑完全不同。

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