ASP.NET Core 8 中 IExceptionHandler
是什么
IExceptionHandler是 .NET 8 引入的全新全局异常处理机制，用于替代旧版
UseExceptionHandler中间件的硬编码路径和有限定制能力。它不是接口实现后自动生效的“即插即用”组件，而是需要显式注册为服务，并由框架在捕获未处理异常时通过 DI 解析调用——这意味着它的生命周期、作用域和依赖注入行为都受 ASP.NET Core 容器控制。
如何注册并实现自定义 IExceptionHandler
必须将实现类注册为 Singleton 或 Scoped 服务（推荐 Singleton），否则可能因作用域不匹配导致解析失败；同时需在
Program.cs中调用
AddExceptionHandler<t>()</t>才会启用。
AddExceptionHandler<myexceptionhandler>()</myexceptionhandler>必须在
builder.Services阶段注册，不能只写实现类而不调用该扩展方法 实现类必须继承
ExceptionHandler<texception></texception>（如
ExceptionHandler<exception></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></invalidoperationexception>优先于
ExceptionHandler<exception></exception>） 若未匹配到具体类型处理器，最终回退到注册的
ExceptionHandler<exception></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。
