IExceptionHandler 是 .NET 8 引入的全局异常处理机制，需显式注册为 Singleton/Scoped 服务并调用 AddExceptionHandler<T>() 启用，通过 DI 解析执行，绕过 MVC 管道直接生成响应，支持泛型异常精确匹配与异步处理。
ASP.NET Core 8 中 IExceptionHandler 是什么
IExceptionHandler 是 .NET 8 引入的全新全局异常处理机制，用于替代旧版 UseExceptionHandler 中间件的硬编码路径和有限定制能力。它不是接口实现后自动生效的“即插即用”组件，而是需要显式注册为服务，并由框架在捕获未处理异常时通过 DI 解析调用——这意味着它的生命周期、作用域和依赖注入行为都受 ASP.NET Core 容器控制。
如何注册并实现自定义 IExceptionHandler
必须将实现类注册为 Singleton 或 Scoped 服务（推荐 Singleton），否则可能因作用域不匹配导致解析失败；同时需在 Program.cs 中调用 AddExceptionHandler<T>() 才会启用。
-
AddExceptionHandler<MyExceptionHandler>()必须在builder.Services阶段注册，不能只写实现类而不调用该扩展方法 - 实现类必须继承
ExceptionHandler<TException>（如ExceptionHandler<Exception>）或直接实现IExceptionHandler接口，后者需手动处理泛型异常匹配逻辑 - 重写的
TryCatchAsync方法中，context.Response默认未开始，需手动设置StatusCode和ContentType，否则返回空响应或 200 - 若想复用 MVC 的
ProblemDetails格式，需手动序列化：调用context.Response.WriteAsJsonAsync(new ProblemDetails { ... })
IExceptionHandler 和旧版 UseExceptionHandler 的关键差异
旧方式靠中间件短路管道并跳转到指定 endpoint（如 /error），而新方式完全绕过路由和控制器，直接在异常发生处生成响应——因此不会触发任何 Filter、Model Binding、Authorization 等 MVC 生命周期环节。
- 旧版可返回 View、重定向、复用 Controller 逻辑；新版只能写原始响应体，无法走 MVC pipeline
- 旧版异常上下文信息有限（仅
HttpContext和原始异常）；新版ExceptionHandlerContext包含Exception、HttpContext、CancellationToken，且支持异步处理 - 多个
IExceptionHandler实现可共存，框架按TException类型精确匹配（如ExceptionHandler<InvalidOperationException>优先于ExceptionHandler<Exception>） - 若未匹配到具体类型处理器，最终回退到注册的
ExceptionHandler<Exception>或默认行为（500 响应）
常见踩坑点：日志、状态码与开发环境行为
.NET 8 默认在开发环境中对某些异常（如 InvalidOperationException ）仍会显示 Developer Exception Page，这会拦截 IExceptionHandler 的执行——只有当异常逃逸出整个 pipeline 且未被其他中间件捕获时，才会进入你的处理器。
- 调试时务必关闭
app.UseDeveloperExceptionPage()（.NET 6+ 已改用app.UseExceptionHandler("/error")+app.UseStatusCodePagesWithReExecute("/error")，但这些仍与IExceptionHandler并行存在，需注意优先级） - 不要在
TryCatchAsync中抛出新异常，会导致进程崩溃或静默失败；建议用logger.LogError(ex, "Global exception handler invoked")记录原始异常 -
context.Response.StatusCode必须显式设置，例如context.Response.StatusCode = StatusCodes.Status500InternalServerError；不设则默认 200 - 若使用
WriteAsJsonAsync，需确保已调用builder.Services.AddControllers().AddJsonOptions(...)配置序列化选项，否则中文可能乱码或 DateTime 格式异常
真正麻烦的是异常类型的粒度控制和跨 service 的上下文透传——比如你希望在仓储层抛出的 DbUpdateException 走一套 JSON 错误结构，而在 API 层抛出的 ValidationException 返回 ProblemDetails，这时就得注册多个泛型处理器，并确保它们之间没有覆盖冲突。这点容易被忽略，直到上线后发现 400 错误全变成了 500。
