如何在async await异步操作中注入异常？

async/await 本身并不提供异常注入能力，它只是语法糖，用于更优雅地处理 Promise。所谓异常注入，本质是在异步流程中主动触发、构造并传递错误信息，让上层 try/catch 能够捕获带有完整上下文的错误（如 traceId、操作名、参数等），而不是简单地将原始错误抛出。

那么，在 async/await 场景下如何实现这种带上下文的异常注入？以下是几种实践中较为可靠的方法。

在 await 前主动抛出错误

最直接的做法：在 await 真正执行之前，根据业务条件主动抛出错误，让控制流直接进入 catch 分支。这种方式最适合参数校验、权限判断、前置状态检查等场景。错误一旦抛出，外层 try/catch 会立即捕获，且 stack trace 清晰指向当前函数的具体位置，便于调试。例如：if (!userId) throw new Error('Missing userId');——简单直接，效果明显。

封装异步调用并重抛增强型错误

避免直接使用 await fetch() 或 await db.query()。建议编写工具函数统一封装异步调用，在 catch 中构造带上下文的错误对象。这样既能保留原始 error.stack，又能附加当前层的额外信息（如 URL、SQL、traceId）。推荐使用自定义错误类，例如 AppError，包含 code、context、cause 等字段，使错误信息更加完整。示例：throw new AppError('DB_TIMEOUT', { sql, traceId }, originalErr);——逐层传递，每个环节都可追加上下文，调用链清晰可查。

在 Promise 构造器中 reject 自定义错误

当需要手动创建 Promise（例如封装回调 API、定时器、事件监听）时，可以在 reject 时传入结构化的错误对象。但需注意：确保该 Promise 被 await 了，否则 reject 不会进入 catch 分支。此外，不要直接 reject 一个字符串，应传入 Error 实例，以保留 stack trace 和类型信息。例如：reject(new AppError('TIMEOUT', { timeout: 5000 }));——清晰、完整、可追踪。

避免常见陷阱

以下几种做法可能导致异常被静默吞掉，或使调试时难以定位问题：

• 调用 async 函数但不加 await，也不接 .catch()——异常会变成 unhandled rejection，无法被 try/catch 捕获。
• 在 catch 中仅 console.error 而不 re-throw，也不返回明确的 fallback——错误被静默忽略，后续逻辑误以为一切正常。
• 使用全局变量存储 traceId 或错误上下文——多请求并发时，变量会被互相覆盖，导致调试信息错乱。
• 拼接 stack 时丢弃原始 error.cause，或不保留 new Error().stack——调用链断裂，排查问题只能靠猜测。