async/await 错误审计需统一入口捕获、结构化记录、按语义分级（如404为warn、超时为error）、保留上下文链路、监听unhandledrejection兜底，并将错误率纳入健康度看板。
async/await 模式下的错误审计，不是简单地“捕获并打印”，而是有目的、可追溯、可归因的错误观测与分析过程。它关注的是：错误何时发生、来自哪一步、是否被处理、是否影响后续逻辑、是否需要告警或重试。核心在于把错误从“异常事件”转化为“可观测数据”。
错误审计的关键动作
统一入口捕获
在每个顶层 async 函数（如 API 路由处理器、定时任务主函数）中用try/catch包裹，确保错误不逃逸到全局未处理 Promise 拒绝。catch 块里不做静默吞错，而是记录结构化信息：时间戳、函数名、调用路径、错误类型、堆栈、关键参数（如 userId、orderId）、HTTP 状态码（若适用）。-
区分错误来源与语义
不是所有 reject 都是“失败”。例如：-
fetch()返回response.status === 404→ 业务不存在错误，应记录为warn级别； - 网络超时或
TypeError: Failed to fetch→ 基础设施问题，标记为error并触发告警； -
JSON.parse()抛出SyntaxError→ 接口数据格式异常，需通知后端校验。
建议用自定义错误类（如ApiError、NetworkError、ValidationError）分类，便于后续过滤与统计。
-
-
保留上下文链路
在 await 前打点日志，比如：console.log('[audit] starting user profile fetch', { userId }); const profile = await fetchUserProfile(userId);这样错误日志能和前序日志关联，还原完整执行路径。生产环境建议用
console.time()或 tracing ID（如reqId）串联请求生命周期。 -
监控未被捕获的拒绝
全局监听unhandledrejection事件，作为兜底审计手段：window.addEventListener('unhandledrejection', event => { console.error('[AUDIT] Unhandled rejection:', { reason: event.reason?.message || String(event.reason), promise: event.promise, timestamp: new Date().toISOString() }); // 上报至 Sentry / 自建日志平台 });这类错误往往暴露逻辑漏洞（如忘记 await、漏写 catch、Promise 构造错误），必须优先修复。
审计结果怎么用
- 日志中提取高频错误码、失败接口、时段分布，定位稳定性短板；
- 对重复出现的
AbortError（用户取消请求）不告警，但对5xx类错误设置阈值告警； - 结合 source map 解析压缩后的堆栈，准确定位原始代码行；
- 将错误率（error rate）纳入接口健康度看板，与成功率、P95 延迟并列展示。
错误审计的本质是让每一次失败都留下可查证的痕迹，而不是等待崩溃才开始排查。
