async/await 使 promise 拒绝表现为同步抛出，可被 try/catch 捕获；需分层捕获异常、保持堆栈完整、避免静默失败，并通过高阶函数或中间件统一错误处理。
async/await 本身不改变异常本质，但改变了异常流转的“路径”——它让 Promise 拒绝（rejection）表现为同步抛出，从而能被 try/catch 捕获。优化异常流转，关键不是掩盖错误，而是让错误在合适的时间、以完整的信息、流向正确的处理层。
明确异常捕获层级：按需决定在哪一层 catch
不是所有异步操作都要在内部 try/catch。过度嵌套会模糊责任边界：
- 业务逻辑层：适合细粒度捕获——比如调用用户服务失败时，降级返回默认头像，而不是中断整个页面渲染
-
服务调用层：适合统一包装——把网络错误、超时、4xx/5xx 封装成不同语义的自定义错误类（如
NetworkError、AuthExpiredError） -
入口层（如 API 路由或组件挂载）：适合兜底捕获——用
.catch()或顶层unhandledrejection监听，防止白屏或静默失败
保持堆栈完整性：避免 throw 丢失原始上下文
直接 throw ex 在 async 函数中会切断原始堆栈；尤其在多层 await 后重新抛出时，调试信息会大幅缩水：
- JavaScript 中推荐用
Promise.reject(ex)或保留原 Promise 链（如return fetch(...).catch(e => { throw e })），而非在catch块里新throw new Error(...) - C# 中应使用
ExceptionDispatchInfo.Throw(ex)（.NET 5+）替代裸throw，确保原始调用栈不被截断 - 若需补充上下文（如“获取订单详情失败，用户ID=123”），建议用
new CustomError(message, { cause: ex })，保留cause链
规避“静默失败”陷阱：fire-and-forget 必须带异常监听
调用 someAsyncFn().then(...) 或直接执行 someAsyncFn() 不 await，等于放弃错误控制权：
- 绝对不要写
someApiCall();—— 这类调用一旦 reject，错误将变成未处理的 Promise rejection - 真要 fire-and-forget，必须显式绑定错误处理器：
someApiCall().catch(console.error)或使用封装好的.SafeFireAndForget(onError) - 在 Node.js 环境中，务必监听全局事件：
process.on('unhandledRejection', (reason) => { /* 记录并告警 */ })
统一错误出口：用高阶函数或拦截器收口
重复写 try/catch 易遗漏且难维护。可抽象通用模式：
- 封装请求函数，自动附加错误分类与重试逻辑：
safeFetch(url, { retry: 2, timeout: 5000 }) - Vue/React 中用自定义 Hook 或 Composable 统一处理 API 错误，并触发 toast 或状态更新
- 后端 Express/Koa 中用中间件捕获 async 路由中的异常：
router.get('/user', wrapAsync(handler))，避免每个路由都写 try/catch
