thread.setdefaultuncaughtexceptionhandler是jvm层全局未捕获异常兜底机制，用于捕获所有线程中未处理的异常；spring cloud gateway则通过自定义errorwebexceptionhandler实现网关层webflux请求异常的统一处理。
1. 全局未捕获异常的兜底捕获 —— 用 Thread.setDefaultUncaughtExceptionHandler
这是 JVM 层面最可靠的“最后一道防线”，适用于所有线程（包括异步任务、定时器、线程池中的 Runnable）。它不依赖任何框架或网关，直接拦截即将导致线程终止的未处理异常。
- 必须在应用启动早期注册（如 main 方法开头）
- 能拿到原始异常、出问题的线程名/ID/组信息
- 适合做日志快照、进程级告警、内存 dump 触发等关键动作
2. 网关层的异常统一治理 —— Spring Cloud Gateway 中自定义 ErrorWebExceptionHandler
网关本身不负责“捕获线程异常”，而是处理请求生命周期内的 WebFlux 异常（如路由失败、过滤器抛错、下游超时）。它的核心是替换默认的 DefaultErrorWebExceptionHandler。
- 通过 @Bean + @Order 控制优先级，覆盖默认错误处理器
- 可结合 ServerWebExchange 获取完整上下文（请求路径、header、traceId）
- 支持返回结构化 JSON 错误体，而非堆栈裸露页面
3. 迭代器/流式场景的异常穿透 —— 关键在于不静默吞掉、保持链路可溯
比如 FastAPI 的 StreamingResponse 或 Reactor 的 Flux，在中间件或 filter 中若 catch 了异常却没 re-throw 或 publish error，就会造成“断层”：上层看不到原始原因，监控无迹可循。
- 过滤器中捕获异常后，应显式调用 exchange.getResponse().setStatusCode() 并 write 错误体，再 return Mono.error(e)
- 避免只 log.warn("忽略") 就结束 —— 这等于主动切断异常链
- 对流式生成器，需确保每个 yield 都在 try-catch 内，并将底层异常包装为业务可识别类型（如 new StreamProcessingException("模型推理失败", cause)）
4. 异常链（Cause Chain）才是修复“断层”的核心手段
无论在哪一层（DAO → Service → Controller → Gateway），只要每层包装异常时都传入原始 cause（new BusinessException("下单失败", e)），就能让最终兜底处理器通过 e.getCause() 逐级回溯，还原真实根因。
- 没有异常链，日志里只有“BusinessException: 下单失败”，无法区分是库存扣减失败，还是支付回调超时
- 有异常链，日志自动打印 Caused by: RedisConnectionException，运维可立即定位到缓存集群问题
