线程池submit异常默认被futuretask静默捕获，必须调用get()才能解包；应统一通过工具方法unwrap executionexception、映射原始异常为带上下文的businesserror，并配合超时控制与回调兜底。
线程池 submit 提交的任务，异常默认被 FutureTask 捕获并静默保存，不打印、不传播、不告警——这不是 bug，是设计。要让它“说话”，得主动拆开 Future 的包装，再把底层异常映射成可识别、可分类、可追踪的业务 Error。关键不在捕获，而在转化路径清晰、错误语义明确、上下文不丢失。
明确异常转化的触发点：必须调用 get() 才能解包
submit 返回的 Future> 是个“异常保险箱”。它内部已捕获 Throwable 并调用 setException(e)，但除非你显式调用 get()（或 get(timeout, unit)），否则异常永远不会抛出，日志里也永远空白。
- 不调用 get() → 异常永久沉睡：任务失败无感知，监控告警全失效
-
调用 get() 但没 catch → 异常原样上抛：通常是
ExecutionException，原始异常被包在getCause()里 - 调用 get() + 正确 unwrap → 才能拿到原始业务异常
封装标准 Error 包装器：统一提取、分类、增强
不要在每个 future.get() 后手写 try-catch。定义一个工具方法，集中做三件事：解包 ExecutionException、识别原始异常类型、包装为带业务码和上下文的 Error。
- 检查是否为
ExecutionException，取getCause() - 若 cause 是
RuntimeException或Error，直接作为根因；若是其他受检异常，按业务规则映射（如SQLException→DatabaseError） - 注入任务标识（如 traceId、taskId）、提交时间、线程池名称等上下文字段
- 返回自定义
BusinessError，含 errorCode（如 "TASK_EXEC_FAILED"）、message、cause、contextMap
避免阻塞等待：异步 get + 超时 + 回调兜底
直接同步调用 future.get() 容易引发线程卡死或响应延迟。生产中应强制设置超时，并用回调承接结果与异常：
- 用
future.get(30, TimeUnit.SECONDS)防止无限等待 - 捕获
TimeoutException→ 包装为TaskTimeoutError - 捕获
ExecutionException→ 交给上述包装器处理 - 推荐配合 CompletableFuture：用
whenComplete((r, ex) -> { ... })统一收口，ex 就是 ExecutionException，逻辑更清晰
补充防御层：任务提交前自动代理包装
即便有包装器，仍可能漏掉未调用 get() 的场景。可在任务提交入口做一层透明代理：
- 封装
SafeSubmit<t></t>方法，接收 Callable，返回增强 Future - 内部自动包装 Callable：在 call() 外加 try-catch，捕获后记录日志 + 上报指标 + 抛出带 traceId 的 RuntimeException
- 这样即使忘记 get()，异常也会通过线程默认 UncaughtExceptionHandler 输出（需提前配置）
- 同时保留原始 Future，兼容需要手动 get() 的场景
本质上，submit 异常不是“丢失”，而是“待领取”。安全优雅的关键，是建立一条从 Future 到 BusinessError 的确定性转化链——不依赖开发者记忆，不绕过超时控制，不牺牲上下文信息。
