JavaScript中try-catch本身不能直接捕获异步错误，仅作用于同步执行上下文；所谓捕获异步错误实为async/await将Promise拒绝转译为同步异常，由语言规范保证，而非try-catch自身能力扩展。
JavaScript 中 try-catch 本身**不能直接捕获异步代码中的错误**，它只作用于当前执行上下文的同步流程。所谓“能捕获异步错误”，其实是与 async/await 协同工作的结果，而非 try-catch 自身能力的扩展。
为什么原生 try-catch 抓不住 setTimeout 或 Promise.then 的错误
根本原因在于 JavaScript 的执行模型：
- 异步任务（如 setTimeout 回调、Promise.then）被推入任务队列，等当前调用栈清空后才执行
- try-catch 块在同步代码执行完就退出，对应的执行上下文和错误监听机制已销毁
- 当异步回调真正运行并 throw 错误时，已不在任何 try 块的保护范围内，错误变成未捕获异常（Uncaught Error 或 Unhandled Rejection）
async/await 是如何让 try-catch “生效”的
async/await 并非增强 try-catch，而是通过语言规范将 Promise 拒绝“转译”为同步异常：
- await 会暂停 async 函数执行，把后续逻辑自动编译进 Promise 链的 .then() 和 .catch()
- 当 await 后的 Promise 被 reject，V8 引擎会在内部触发一个语义上等价于 throw 的同步异常
- 这个异常立即被最近的 catch 块捕获，整个过程由 ECMAScript 规范保证
哪些异步错误依然无法被 try-catch 捕获
即使用了 async/await + try-catch，以下情况仍会逃逸：
立即学习“Java免费学习笔记（深入）”；
- 全局未处理的 Promise rejection（如漏写 .catch 或顶层 await 失败且无 try 包裹）
- 事件处理器中的错误（如 img.onerror = () => { throw … }），回调是独立执行上下文
- 定时器回调、Web Worker 内部、跨域脚本抛出的错误，它们脱离当前 JS 执行流
正确使用 try-catch 处理异步错误的关键细节
不是加了 try-catch 就万事大吉，必须注意执行时机和结构：
- await 必须写在 try 块内：漏写 await 或写在 try 外，得到的是 pending Promise，不会触发 catch
- 区分网络层与业务层错误：fetch 成功但 res.ok 为 false、data.code !== 0 等都不是 JS 异常，需手动检查并 throw
- 避免混合写法：不要在 try 中调用 Promise 链却不 await，也不要在 .then 中抛错却没配 .catch
- 调用方仍需兜底：async 函数内部有 try-catch，最终返回的 Promise 仍可能被 reject，事件回调或 useEffect 中应加 .catch() 或顶层处理
