async/await 并不直接拦截回调函数中的异常，而是通过 try/catch 捕获 await 表达式所返回的 Promise rejection。核心要点是：只有被 await 的 Promise 被 reject 时，错误才会进入 catch 块；而传统回调函数（如 fs.readFile 的回调）内部抛出的异常，无法被 try/catch 捕获——除非先将回调转换为 Promise。

因此，async/await 的核心机制在于：它不会自动捕获回调中的 throw 异常，只关注 await 后面的 Promise 是否被 reject。如果使用原始回调（如 setTimeout 或 fs.readFile 的 error-first 风格），回调内部的异常会像幽灵般越过 try/catch 的作用域。只有将回调包装成 Promise 后，await 才能感知到错误，并被外层的 catch 捕获。

确保回调函数被正确转换为 Promise

要让 await 和 try/catch 在回调场景下生效，必须先把原始回调封装成 Promise。具体怎么做？

• 使用 Promise 构造器手动封装：将回调的 error 参数转换为 reject，成功结果转换为 resolve。
• 切勿在回调中直接 throw —— 这只会导致未捕获异常，无法中断 await 的流程。
• 推荐使用现成工具，例如 Node.js 的 util.promisify，或自行封装一个可复用的 promisify 函数，方便高效。

正确使用 try/catch 包裹 await 表达式

catch 只抓当前 await 所等待的 Promise 的 rejection，而不是整个 async 函数体内任意抛出的异常。这一点很容易踩坑：

• 错误写法：await someAsync(); throw new Error('oops'); —— 这个 throw 不会被外层 catch 捕获，除非它发生在 await 之后且未被处理。
• 正确写法：将所有可能出错的异步操作都用 await 包裹，并放在 try 块内。
• 多个 await 可以共用一个 try/catch 块，也可以各自独立处理，根据业务需求灵活选择。

警惕非 Promise 回调中的“幽灵异常”

如果在 async 函数里直接使用传统回调（比如 setTimeout(() => { throw 'boom' }, 100)），这个异常会完全脱离 try/catch 的作用域。它会变成未捕获异常（Uncaught Exception），轻则触发 unhandledrejection 事件，重则直接 crash 进程。解决办法？

• 要么避免在 async 函数中直接使用回调，要么手动用 try/catch 包裹回调内部逻辑——但后者会破坏 await 语义，不推荐。
• 更安全的做法是：将所有异步逻辑统一转换为 Promise 链，让 await 统一管理。

处理多个并发异步操作中的异常

当使用 Promise.all 或 Promise.allSettled 时，异常行为截然不同，选对工具很重要：

• Promise.all([p1, p2])：任一 Promise reject 会导致整个 all 立即 reject，可由外层 catch 统一捕获。
• Promise.allSettled([p1, p2])：总会 resolve，结果数组包含每个 Promise 的 status 和 value/reason，需手动遍历检查每个项是否 fulfilled。
• 如果需要部分失败仍继续执行，优先选择 allSettled，再遍历结果逐一判断。