useexceptionhandler 必须在 userouting 之后、useendpoints 之前注册，否则无法捕获路由前异常；开发环境需禁用 usedeveloperexceptionpage；仅捕获 http 请求生命周期内异常，不处理后台任务等场景；推荐用 problemdetails 返回标准错误，避免手写 try/catch；自定义异常可类型判断差异化响应；异步操作必须显式 await，否则异常逃逸；异常处理器自身不可抛异常。
ASP.NET Core 里 UseExceptionHandler 怎么配才真正生效
它不是“加了就自动兜住所有异常”的银弹，必须放在中间件管道的正确位置，且不能和 UseDeveloperExceptionPage 冲突。
-
UseExceptionHandler必须在UseRouting之后、UseEndpoints之前注册，否则 404 或路由前抛的异常会漏掉 - 开发环境如果同时启用了
UseDeveloperExceptionPage，它会抢在UseExceptionHandler前拦截异常并直接返回 HTML 页面——上线前务必确认已移除或条件启用 - 它只捕获 HTTP 请求生命周期内的异常（比如 Controller 执行中、Model Binding 失败），不处理后台任务、定时器、中间件初始化等场景抛出的异常
为什么 try/catch 在 Action 里写一堆不如用 ProblemDetails 返回标准错误
手写 try/catch 容易重复、状态码错乱、丢失堆栈上下文，而 ASP.NET Core 原生支持 RFC 7807 标准的 ProblemDetails，结构清晰还自带 Content-Type 和 Status Code。
- 直接 return
StatusCode(500, new ProblemDetails { Title = "服务异常", Detail = ex.Message })，比手动构造 JSON 更可靠 - 配合
ApiController特性时，BadRequest(ModelState)会自动转成ProblemDetails，字段验证失败也能统一格式 - 注意：不要在
ProblemDetails里暴露ex.StackTrace到生产环境，敏感信息要过滤
自定义异常类型怎么被 ExceptionHandler 捕获并差异化响应
默认的异常处理器对所有 Exception 一视同仁，但业务常需要区分 ValidationException、NotFoundException 等，返回不同状态码和消息。
- 写一个继承
Exception的类，比如BusinessRuleException，并在构造函数里设好StatusCode属性 - 在
UseExceptionHandler配置里，用app.UseExceptionHandler("/error/business")分流，再配单独的MapControllerRoute处理该路径 - 更轻量的做法：在全局异常处理中间件里用
if (ex is NotFoundException)类型判断，手动设置context.Response.StatusCode = 404
中间件里异步操作抛异常，UseExceptionHandler 为什么抓不到
典型场景是 HttpContext.Request.Body 流读取、HttpClient 调用、EF Core SaveChangesAsync 这些 await 操作没被 await 或没包进 try/catch，导致异常逃逸出请求上下文。
- 确保所有
async方法都显式await，尤其别在 lambda 里漏掉（比如app.Use(async (ctx, next) => { await next(); ... })） -
UseExceptionHandler只捕获同步异常和被await捕获的异步异常；未 await 的 Task 抛异常会变成未观察到的异常，触发进程级事件，不会走 HTTP 异常流 - EF Core 6+ 开始，
SaveChangesAsync抛出的DbUpdateException是同步包装过的，能被捕获；但低版本若用Task.Run包一层，就可能绕过
最常被忽略的是：异常处理器本身不能抛异常。一旦 ExceptionHandler 内部出错（比如日志组件崩了、JSON 序列化失败），整个请求就彻底挂掉，连 500 都回不出去。建议在异常处理逻辑里加最简兜底，比如只写日志 + 返回空 ProblemDetails。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
