核心是建立可统计、可归因、可持续追踪的异步错误监控机制，需唯一标识调用、绑定上下文、统一收集分维度计数、捕获漏网错误，并按业务逻辑区分有效异常。

监控 async/await 模式下异步操作的错误频率，核心不是“只看有没有错”，而是建立可统计、可归因、可持续追踪的机制。重点在于把错误从“被抛出”变成“可计量”的事件。

给每个关键异步调用打上唯一标识

错误频率统计的前提是能区分“谁错了”。不能只记录 error.message，而要绑定上下文：

• 在 try/catch 中手动记录函数名、API 路径、关键参数（如用户 ID、请求类型）
• 例如：logError('fetchUserProfile', { userId: 123 }, error)
• 避免泛化日志如 “请求失败”，否则无法聚合分析是哪个接口、哪类用户、哪个版本高频出错

统一收集 + 分维度计数

错误日志本身不等于频率数据，需要后端或前端埋点系统做聚合：

• 前端可维护一个轻量计数器：按错误码（如 401、500）、模块（login、cart）、时间窗口（每分钟/每小时）累加
• 上报时附带时间戳和标签，服务端用 Prometheus 或 ELK 做实时聚合图表
• 例如：发现 fetchOrderList 在过去 10 分钟内错误率突增至 12%，立即触发告警

捕获漏网错误，补齐统计盲区

仅靠 try/catch 会漏掉未 await 的 Promise 或链路中途 reject 的情况：

• 监听全局 unhandledrejection 事件，记录 e.reason 和 e.promise 的堆栈
• 对所有顶层 async 入口（如按钮点击、页面加载）强制包裹 try/catch，确保无死角
• 避免使用 .catch(() => {}) 静默吞错——这会让错误彻底消失，频率统计归零但问题仍在

结合业务逻辑判断“有效错误”

不是所有 reject 都该计入故障率：

• 主动 throw 的业务错误（如“库存不足”）属于正常流程，不应拉低成功率指标
• 网络超时、解析失败、5xx 响应等才是需监控的异常错误
• 建议在错误对象上挂载 isTransient: true 或 category: 'network' 字段，上报时过滤分类