异步异常逃逸本质是捕获作用域未覆盖异常实际抛出点，需通过全局钩子验证、定位无效catch位置（如await前包裹、execute提交忽略异常），并确保try-catch落在await/then/get等完成点上。
异步方法中异常“完全失控逃逸”，本质是异常未被任何有效作用域捕获，最终被运行时静默丢弃或触发全局未处理事件（如 .NET 的 TaskScheduler.UnobservedTaskException、Java 的 uncaughtExceptionHandler、JS 的 unhandledrejection）。关键不在“有没有 try-catch”，而在于捕获块是否落在异常实际抛出的执行路径上——即作用域是否真正覆盖到异步操作的完成点。
确认异常是否真的逃逸了
先验证问题现象，避免误判：
- 检查日志系统是否收到该异常堆栈（尤其注意异步线程名、协程 ID 或 Task ID）
- 启用语言/框架级全局钩子：.NET 中订阅
TaskScheduler.UnobservedTaskException；Java 中设置Thread.setDefaultUncaughtExceptionHandler；JS 中监听window.addEventListener('unhandledrejection') - 观察行为：主线程继续运行、无错误提示、任务看似“消失”但结果未写入、数据库无记录——这些是典型逃逸信号
定位捕获块失效的常见位置
以下场景中，即使写了 try-catch，也形同虚设：
-
在 await 前包裹，但异常发生在 await 后续延续中：例如
try { var res = await apiCall(); } catch {...}是安全的；但若写成try { var task = apiCall(); } catch {...} await task;，则 catch 完全无效——异常发生在 await 阶段，而非 task 创建时 -
使用 execute() 提交 Runnable，却只在提交侧 try-catch：Java 中
executor.execute(() -> { throw new RuntimeException(); });的异常不会抛给调用方，必须靠线程工厂设置UncaughtExceptionHandler -
@Async 方法内未捕获，且调用方未处理返回的 Future：Spring 中
@Async方法若抛异常，且调用方未调用future.get()，异常就永远锁在 Future 内部 -
协程 launch 启动后未加 try-catch，又没配置 CoroutineExceptionHandler：Kotlin 中
launch { riskyOperation() }出错只会打印日志，父作用域不受影响，也无传播
修复策略：让捕获作用域落到异常落点
不是加一层 try-catch 就够，要让它罩住异常真正“落地”的那一行：
- .NET：所有
await表达式前后都应处于 try 块内；公共库方法末尾统一加.ConfigureAwait(false)避免上下文切换干扰异常传播路径 - Java：优先用
submit(Callable)替代execute(Runnable)，确保能通过Future.get()主动拉取异常；或为线程池指定带异常处理器的 ThreadFactory - Spring：@Async 方法本身需包含完整异常处理逻辑，或返回
CompletableFuture并链式调用exceptionally() - 前端 Promise：拒绝必须显式
.catch()，或用async/await配合 try-catch；避免只写promise.then(success)而忽略错误分支
验证修复是否生效
不能只看代码有没有 catch，要实测异常能否被观测到：
- 在目标异步逻辑中主动抛出一个带唯一标识的测试异常（如
throw new Exception("ASYNC_TEST_123")） - 确认该字符串出现在日志、监控告警或调试器断点中
- 检查线程池队列长度、协程作用域状态、Task.IsFaulted 属性等运行时指标是否反映失败
