asp.net core中间件生效需满足三条件：注册位置正确、invokeasync严格匹配public async task invokeasync(httpcontext context)签名、依赖服务按规则注入；usemiddleware()支持di，app.use()为纯委托；漏await _next(context)将短路后续管道。
ASP.NET Core 中间件不是“注册完就自动生效”的黑盒，核心问题就三个：注册位置错、InvokeAsync 没 await _next(context)、依赖服务放错了地方——任一出错，请求就卡死、状态码是 200 但没响应、或日志里根本看不到执行痕迹。
InvokeAsync 方法签名必须严格匹配框架约定
框架靠反射找入口方法，任何偏差都会在运行时报 InvalidOperationException: No public Invoke or InvokeAsync method found，而不是编译错误。
- 必须是
public async Task InvokeAsync(HttpContext context)—— 方法名、返回类型、第一个参数名和类型都不能改 - 不能写成
Invoke（同步）、Handle、Process等其他名字 - 不能返回
void或Task<string></string>；即使内部没 await，也必须声明为async Task - 参数名不能是
ctx或httpContext，必须是context（名字不强制，但多数模板和诊断工具默认认context，改名易引发排查混淆） - 额外依赖（如
ILogger<mymiddleware></mymiddleware>）可作为后续参数传入，但不能塞进构造函数再试图在InvokeAsync里用字段访问——作用域服务会复用出错
UseMiddleware() 和 app.Use() 的注册方式不能混用
两者底层行为完全不同，选错会导致依赖注入失效、上下文提前释放，甚至 DbContext 报 ObjectDisposedException。
-
app.UseMiddleware<mymiddleware>()</mymiddleware>：走 DI 容器，支持构造函数注入单例服务（如ILogger<mymiddleware></mymiddleware>），但作用域服务（如IDbContextFactory<appdbcontext></appdbcontext>）**必须放在InvokeAsync参数里**，否则跨请求复用 -
app.Use((context, next) => { ... })：纯委托，无 DI 注入能力；若需服务，得手动从app.Services.GetRequiredService<t>()</t>拿，且next必须写成await next(context)，写成next(context)或next()会跳过后续管道 - 别在
Use里new MyMiddleware(...)—— 它不参与生命周期管理，Dispose不会被调用
await _next(context) 漏掉就等于删掉整个后续管道
这是最隐蔽也最致命的坑。中间件不自动调用下一个，漏掉这句，UseRouting、UseEndpoints、UseAuthorization 全部失效，客户端可能收不到响应或卡住。
- 错误写法：
_next(context);（没 await）→ 编译通过，但等同于短路，后续中间件完全不执行 - 调试技巧：在
InvokeAsync开头和结尾加Console.WriteLine("enter")/"exit"，只看到 “enter” 没 “exit”，基本就是这里断了 - 读取
context.Response.StatusCode必须在await _next(context)之后；修改它必须在之前，否则抛InvalidOperationException: Headers are read-only - 短路逻辑（如鉴权失败）要显式
return或throw，避免误执行await _next(context)
中间件顺序错一位，StatusCode 或 Body 就全错
管道是纯顺序执行，框架不做合理性校验。顺序错了，不是报错，而是逻辑静默错乱。
-
app.UseAuthentication()必须在app.UseAuthorization()之前，否则context.User.Identity.IsAuthenticated始终为false - 日志中间件若注册在
app.UseExceptionHandler()之后，就捕获不到未处理异常 - 想记录最终响应状态码？必须把日志中间件放在
UseAuthorization之后、UseEndpoints之前；放太前，打印的是初始 200；放太晚，可能已被UseExceptionHandler改写但你没看到 -
app.UseStaticFiles()要放在app.UseRouting()之后、app.UseEndpoints()之前，否则静态文件请求被路由中间件拦截并返回 404
真正难的不是写中间件类，而是理解每个 await _next(context) 是请求/响应阶段的分水岭，以及每个 app.UseXXX() 调用在管道中实际占据的位置——这两点一旦模糊，问题就会以“请求无声消失”或“状态码始终不对”这种最难 debug 的方式出现。
