混合微服务中线程池异常被包装为executionexception导致全局异常处理器失效，需在@exceptionhandler(executionexception.class)中主动解包getcause()并重抛；同时通过safeasynctask封装、completablefuture异常分支处理及feign自定义errordecoder实现预防与透传加固。
混合微服务中，线程池异常被包装成 executionexception 后，常导致全局异常处理器（如 @restcontrolleradvice）完全失效——因为原始业务异常被“藏”在 getcause() 里，上层只看到一个通用的、非业务语义的包装异常，从而跳过你精心定义的 @exceptionhandler(businessexception.class)。这不是配置遗漏，而是异常链断裂造成的处理断层。
识别 ExecutionException 的真实根因
它几乎总出现在使用 Future.get()、CompletableFuture 或 Spring 的 @Async 场景中。例如：
- 调用
taskService.submit(() -> { throw new BusinessException("ORDER_NOT_FOUND"); }).get(); - 或
@Async方法内部抛出业务异常，但主线程通过Future获取结果时未解包
此时捕获到的是 ExecutionException，而 BusinessException 只是它的 cause，不会触发对应异常处理器。
统一解包：在全局异常处理器中主动展开
不要依赖框架自动匹配原始异常类型。在 @ExceptionHandler(ExecutionException.class) 中，强制提取并重抛其 cause：
- 检查
ex.getCause() != null - 若 cause 是你定义的业务异常（如
BaseException、GlobalException），直接调用同名@ExceptionHandler方法处理 - 若 cause 是其他运行时异常（如
NullPointerException），按兜底逻辑处理（记录堆栈、返回 500）
这样可复用已有异常处理逻辑，避免重复编码。
预防性封装：让异步任务自带异常语义
在提交异步任务前，统一做一层包装，把业务异常提前“暴露”出来：
- 不直接提交
Runnable，而是提交一个SafeAsyncTask，其run()内部已包裹try-catch - 捕获后不静默，而是将
BusinessException以标准方式抛出，或写入线程本地日志上下文供后续追踪 - 对
CompletableFuture，优先使用handle()或exceptionally()显式处理异常分支，而非依赖get()
跨服务调用时的异常透传加固
当异步任务涉及 Feign/RestTemplate 调用远程服务，对方返回错误响应（如 400/500）时，容易被客户端 SDK 封装为 ExecutionException + FeignException：
- 在 Feign 配置中自定义
ErrorDecoder，将 HTTP 错误状态码映射为你自己的GlobalException子类 - 确保该子类继承自
RuntimeException，且能被全局处理器识别 - 避免在远程调用后手动
if (response.status() == 400) throw new BusinessException(...)—— 这种写法会绕过统一解包路径
