应封装带受检异常的函数式接口（如IOConsumer）并在执行处用UncheckedIOException包装；CompletableFuture中需抽离DB操作并分类处理；@Async异常须显式通过CompletableFuture捕获；CountDownLatch等需手动传递异常。
Callback里抛IOException编译不通过怎么办
Java里写Runnable或Consumer回调时，如果里面调了可能抛IOException的方法，编译器直接报错——因为这些函数式接口的accept()或run()没声明throws Exception。这不是你代码写错了，是函数签名卡死的。
常见做法是用try-catch吞掉异常，但这样会丢掉错误上下文；或者强行throw new RuntimeException(e)，又让调用方没法针对性处理。
- 推荐封装一个带受检异常的函数式接口，比如
IOConsumer<t></t>，定义void accept(T t) throws IOException - 在真正执行回调的地方（比如线程池提交前），用
try-catch兜底并转成RuntimeException，但保留原始异常为cause：new UncheckedIOException(e) - 别用
Exception泛型捕获，避免把NullPointerException也包进去——只针对你明确知道的受检异常类型做转换
CompletableFuture.thenAccept()里怎么安全处理SQLException
CompletableFuture的thenAccept()、thenApply()等方法签名都不允许抛受检异常，所以直接在lambda里写connection.prepareStatement()会编译失败。
这里的关键不是“怎么绕过编译”，而是“在哪一层做异常分类和路由”。数据库操作出错，大概率要重试、降级或告警，而不是当场转成RuntimeException扔给exceptionally()随便打个日志。
立即学习“Java免费学习笔记（深入）”；
- 把DB操作单独抽成一个私有方法，返回
Optional<result></result>或自定义Result<t></t>容器，内部消化SQLException并区分是连接超时、唯一约束冲突还是语法错误 - 在
thenApply()里调这个方法，返回值为null或empty时，再用handle()统一判断并触发对应策略 - 避免在
thenAccept()里做Thread.sleep()或同步IO——异步链里混同步阻塞，会拖垮整个ForkJoinPool.commonPool()
Spring @Async方法里throw ParseException为什么没进@ExceptionHandler
@Async方法运行在线程池的新线程里，和Web请求线程完全隔离。@ExceptionHandler只对DispatcherServlet捕获的Controller异常生效，对异步线程里的异常根本看不见。
你以为加了@EnableAsync就自动继承了MVC的异常处理机制，其实没有。它连事务传播都要手动配TransactionSynchronizationManager，更别说异常了。
- 必须显式用
CompletableFuture包裹@Async方法返回值，然后在调用方用whenComplete()或exceptionally()处理 - 如果用的是
void返回类型，那就只能靠Future对象的get()来拿异常——但注意这会阻塞，别在Web层直接get() - 别依赖
UncaughtExceptionHandler全局兜底：它只抓未被捕获的Throwable，而Spring的@Async默认会吃掉异常并记录WARN日志，你根本收不到通知
用CountDownLatch等同步工具时，异常被吞掉怎么定位
写测试或临时脚本时常用CountDownLatch等工具等异步完成，但一旦回调里抛异常，主线程await()结束后压根不知道发生了什么——异常被线程静默吞了，控制台只有空行。
这不是工具的问题，是Java线程模型决定的：子线程异常不会自动冒泡到父线程。你得自己搭桥。
- 在回调lambda最外层加
try-catch，把异常存到共享变量里，比如AtomicReference<throwable></throwable> - 主线程
await()后检查这个引用，不为空就throw ref.get()，确保异常可追溯 - 如果用的是
ExecutorService，可以改用submit(Runnable)拿到Future，再调future.get()——它会把执行异常包装成ExecutionException抛出
异步回调的异常从来不是“要不要处理”的问题，而是“在哪个上下文、以什么形态暴露出来”——漏掉这一层设计，后面所有重试、监控、告警都是空中楼阁。
