关键在于显式触发异常释放：FutureTask捕获异常是设计机制，不调用get()或等效回调则异常静默沉睡；须用safeGet、CompletableFuture.exceptionally/handle统一兜底，并透传上下文确保可追溯。

关键不是“避免吞没”，而是让异常必然暴露、可定位、可追溯。FutureTask 本身的设计就是捕获并暂存异常，这不是 bug，是机制；真正的问题在于开发者未主动触发异常释放，导致错误静默。

必须显式调用 get() 或等效机制

submit() 提交 Callable 后，异常被封装进 Future，但不会自动抛出。不调用 get()、isDone() 后跟 get()、或未注册完成回调，异常就一直“沉睡”在 Future 对象里。

• 哪怕任务已失败，future.isDone() 返回 true，但不 get() 就拿不到异常
• 日志里完全看不到堆栈，监控也无异常指标，排查时容易绕远路查网络、DB、中间件
• 推荐统一包装 submit：用带超时和日志的 safeGet() 替代裸 get()

优先用 CompletableFuture 替代原始 Future

CompletableFuture 天然支持链式异常处理，无需阻塞式 get() 就能兜住异常：

• 用 exceptionally() 捕获并记录原始异常（注意：它接收的是 cause，不是 ExecutionException）
• 用 handle() 统一处理成功/失败，避免漏分支
• 所有回调必须显式指定线程池（如 .thenApplyAsync(fn, pool)），防止 fallback 逻辑意外跑在主线程或 commonPool 中，破坏上下文一致性

复用上下文时，异常传播必须穿透线程边界

若需将 MDC、事务上下文、用户身份等透传到异步线程，仅靠 InheritableThreadLocal 不够健壮——FutureTask 内部可能复用线程，旧上下文残留会导致错乱，异常发生时更难关联源头。

• 提交任务前，快照关键上下文（如 traceId、userId）并显式传入 Callable/Runnable
• 在异常处理逻辑（如 exceptionally 回调）中，主动把快照信息注入日志，确保每条异常日志自带上下文标签
• 避免依赖 ThreadLocal 自动继承，尤其在线程池长期存活、线程复用频繁的场景

线程池关闭阶段必须同步等待关键任务

如果 shutdown(wait=false)，未完成的 Future 会被丢弃，其中的异常永远无法触达——既不打印，也不通知，彻底消失。

• 业务关键任务提交后，务必在 shutdown 前调用 awaitTermination() 并检查未完成数
• 或改用 shutdownNow() + 主动 cancel() + get() 检查每个 future 状态
• 禁止在 JVM 关闭钩子（atexit）或对象析构（__del__ / finalize）中依赖 Future 状态，时机不可控，极易漏异常