spring异步方法异常默认不传播且静默丢失，需通过@enableasync、代理调用、线程名验证确认异步执行；默认由loggingerrorhandler记录warn日志，须配置asyncconfigurer的asyncuncaughtexceptionhandler捕获处理。
Spring 异步方法中抛出的异常默认不会传播到调用方线程，若未配置自定义异常处理器，会静默丢失或仅记录在日志中——这正是“异常逃逸”的典型表现。排查核心在于确认异步异常是否被拦截、是否被正确处理，而非单纯看控制台有没有报错。
确认 @Async 方法是否真正在异步线程中执行
异常逃逸的前提是方法确实走异步路径。常见误判是：方法加了 @Async，但因配置缺失或调用方式错误，实际仍同步执行，此时异常会正常抛出并被捕获（比如被全局异常处理器捕获），造成“没逃逸”的假象。
- 检查是否启用异步支持：
@EnableAsync必须出现在某个被 Spring 扫描到的配置类上（如主启动类或@Configuration类），且该类不能被@ComponentScan(excludeFilters = ...)排除 - 验证调用是否触发代理：避免自调用（即同一个类内 A 方法调 B 方法，B 标记
@Async）；必须通过 Spring 容器注入的 Bean 实例调用，才能走 AOP 代理 - 在
@Async方法内打印当前线程名（Thread.currentThread().getName()），对比调用方线程，确认线程已切换（如从http-nio-8080-exec-1变为task-1）
检查异步异常是否被默认机制吞掉
Spring 对未捕获的异步异常有默认行为：交由 SimpleAsyncTaskExecutor 的内部逻辑处理，最终调用 LoggingErrorHandler 记录 WARN 日志，但不中断流程、不通知调用方。这意味着异常看似“消失”了。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 开启 DEBUG 日志级别，搜索关键词
AsyncUncaughtExceptionHandler或uncaught exception，确认是否有类似Failed to complete async method的日志 - 若完全无日志，说明异常可能被更上层的 try-catch 吞掉，或发生在 Spring 代理之外（如线程池拒绝策略触发时）
- 注意：即使你配置了全局
@ControllerAdvice，它对异步线程中的异常也完全无效——因为那是另一个线程，不经过 Web MVC 的拦截链路
配置并验证 AsyncConfigurer 自定义异常处理器
真正解决逃逸，必须显式提供 AsyncUncaughtExceptionHandler，这是唯一能捕获异步线程中未处理异常的扩展点。
- 实现
AsyncConfigurer接口，并重写getAsyncUncaughtExceptionHandler()方法 - 返回一个非 null 的处理器实例，例如记录 ERROR 日志 + 发送告警（不要只打 INFO）
- 确保该配置类被 Spring 扫描到（包路径在
@SpringBootApplication默认扫描范围内，或显式用@ComponentScan包含） - 测试时，在
@Async方法中主动抛出运行时异常（如throw new RuntimeException("test async crash")），观察是否触发你定义的处理器逻辑
排查线程池级异常吞没风险
如果使用自定义 ThreadPoolTaskExecutor，还需检查其拒绝策略和异常处理配置：
- 若设置
setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy())，任务会在调用线程执行，异常将同步抛出，不属于“异步逃逸”范畴 - 若使用
AbortPolicy或DiscardPolicy，任务被拒绝时不会抛异常，而是直接丢弃——这属于任务丢失，不是异常逃逸，但效果类似 - 确保线程池的
setThreadFactory设置了有意义的线程名，便于日志追踪；未命名线程会让异常堆栈难以关联到具体业务
