try-catch 本身无法捕获异步错误，因其仅作用于同步执行上下文；async/await 通过将 promise 拒绝转译为同步 throw 行为，使 catch 能响应；但事件回调、定时器、全局 promise 拒绝等仍会漏捕。
try-catch 本身不处理异步事件流，它只响应当前执行上下文中的同步错误。所谓“能捕获异步错误”，是 async/await 与 try-catch 协同工作的结果，不是 try-catch 自身能力的扩展。
为什么原生 try-catch 抓不住异步错误
核心在于 JavaScript 的执行模型：
- 异步任务（如 setTimeout 回调、Promise.then、fetch 响应）被推入任务队列，等当前调用栈清空后才执行
- try-catch 块在同步代码执行完就退出，其执行上下文和错误监听机制已销毁
- 当异步回调运行并 throw 错误时，已不在任何 try 块保护范围内，错误直接变成未捕获异常
async/await 是如何让 try-catch “生效”的
await 不是等待，而是控制流暂停与 Promise 状态机的联动：
- async 函数返回 Promise，await 将后续逻辑自动编译为 .then() 和 .catch() 链
- 当 await 后的 Promise 被 reject，V8 引擎在内部将其转译为同步语义的 throw 行为
- 这个抛出立即触发最近的 catch 块，由语言规范（ECMAScript 2017+）保证
哪些异步错误依然无法捕获
即使用了 async/await + try-catch，以下场景仍会漏掉错误：
- 全局未处理的 Promise rejection（例如顶层 await 失败但没被 try 包裹）
- 事件处理器中的错误（如 img.onerror = () => { throw … }），因为事件回调是独立执行上下文
- 定时器回调、Web Worker 内部、跨域脚本抛出的错误，它们脱离当前 JS 执行流
在复杂异步流程中正确使用 try-catch 的关键
重点不在“加不加”，而在于“在哪加、怎么分层、如何传递上下文”：
- 只包裹真正可能抛错的 await 表达式，避免把校验、UI 更新等无关逻辑全塞进一个 try 块
- 每个 await 单独或按语义分组包裹，保持 try 块轻量，便于定位错误来源
- finally 中可 await 清理操作（如关闭连接），但要注意：它会覆盖原异常，且必须确保函数本身是 async 的
- 并发场景优先用 Promise.allSettled 或对子 Promise 单独 .catch()，而非依赖外层 try-catch
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
