minimal api 的 endpointfilter 不是 mvc 的 actionfilter，不走 mvc 管道、不支持自动模型绑定验证或全局注册；需用 addendpointfilter 链式注册内联过滤器，显式调用 await next(context) 才能继续执行；参数通过 context.getargument(index) 获取；短路响应必须用 results.*()；多个过滤器前置逻辑按添加顺序（fifo）、后置逻辑倒序（filo）执行；复用逻辑应实现 iendpointfilter 接口并从 requestservices 解析服务；可对 mapgroup 分组批量注册；无法获取 modelstate 或自动验证结果，需手动校验。
Minimal API 的 EndpointFilter 不是 MVC 的 ActionFilter，它不走 MVC 管道，也不支持自动模型绑定验证或全局注册——想靠它替代控制器过滤器，会踩坑。
怎么注册单个端点的内联过滤器
用 AddEndpointFilter 链式调用，传入一个 async (context, next) => { ... } 委托。这个委托必须显式调用 await next(context) 才能继续执行原端点逻辑，否则请求就卡住或直接短路。
-
context.GetArgument<t>(index)</t>是获取路由/查询参数的唯一方式，不能用HttpContext.Request.Query或RouteData—— Minimal API 不暴露这些 - 短路响应必须返回
Results.*()（如Results.Problem()、Results.Unauthorized()），不能 throw 异常，否则会触发全局异常中间件，绕过你本意的“拦截” - 多个
AddEndpointFilter调用时，前置逻辑（await next前）按添加顺序执行（FIFO），后置逻辑（await next后）则倒序执行（FILO）
怎么复用过滤器逻辑：IEndpointFilter 接口实现
当同一套校验或日志逻辑要用于多个端点，别重复写 lambda，而是实现 IEndpointFilter 接口。它的 InvokeAsync 方法签名固定，且支持从 context.HttpContext.RequestServices 解析 DI 服务。
- 不要在构造函数里依赖注入耗时服务（如数据库上下文），因为过滤器实例可能被缓存；应在
InvokeAsync内按需获取：context.HttpContext.RequestServices.GetRequiredService<ilogger>()</ilogger> - 实现类必须是无状态的，不能保存
context或next到字段里——它们只对当前请求有效 - 注册时直接写
.AddEndpointFilter<myauthfilter>()</myauthfilter>，框架会自动从 DI 容器解析，前提是该类型已通过builder.Services.AddScoped<myauthfilter>()</myauthfilter>注册
怎么给整个路由分组批量加过滤器
用 MapGroup 创建分组后，再链式调用 AddEndpointFilter，该分组下所有子端点都会继承该过滤器。这是避免重复注册最实用的方式。
-
MapGroup返回的是IEndpointConventionBuilder，它支持AddEndpointFilter，但不支持UseAuthentication这类中间件——那些得在app.Use*阶段注册 - 分组前缀（如
/api/v1）不能带变量，否则MapGroup会报错；路径变量只能放在子MapGet里 - 如果分组内某个端点需要跳过某过滤器，目前没有内置“排除”机制，只能拆出单独路由，或在过滤器内部用
context.HttpContext.Request.Path做条件判断
为什么过滤器里拿不到 ModelState 或自动验证结果
Minimal API 绕过了 MVC 管道，所以没有 ModelState、没有 [Required] 自动触发、也没有 ApiController 特性带来的默认行为。参数校验必须手动做。
- 简单类型（
string、int）绑定失败时，context.GetArgument<t>(0)</t>会抛InvalidOperationException，不是返回 null——必须 try/catch - 复杂对象（如
record）只支持 JSON body 绑定，且不校验属性特性；若需验证，得自己调用Validator.TryValidateObject或用第三方库 - 别指望
AddEndpointFilter能像 MVC 的ActionFilterAttribute那样读取方法上的自定义特性——Minimal API 的委托没有反射元数据可查
真正容易被忽略的是执行顺序和上下文生命周期：每个过滤器的 context 和 next 都是单次请求专属，跨请求复用会导致状态污染；而 next 不是“下一个中间件”，它只代表当前端点处理链的剩余部分——一旦漏掉 await next(context)，端点逻辑就永远不会执行。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
