前端接口失败率统计与上报需分层捕获失败（封装请求拦截+被动监听）、按分钟滑动窗口聚合计算、用sendbeacon轻量脱敏上报，并联动快照与多维指标下钻定位问题。
前端接口失败率统计与上报，核心是精准识别请求失败、统一归因、持续采样、轻量上报，不能干扰主流程，也不能漏报关键失败（比如用户刚点击提交就断网）。
一、怎么准确识别“失败”
仅靠 catch 或 onerror 不够——它可能被业务层吞掉，也可能漏掉 fetch 超时、网络中断、CORS 阻断等静默失败。推荐分层捕获：
-
主动请求层拦截：所有业务请求统一走封装后的
request()函数，在内部标记 status !== 2xx、网络异常（TypeError: Failed to fetch）、AbortError、超时等为失败 -
被动监听补充：对未封装的请求（如第三方 SDK、动态 script 加载），用
window.addEventListener('error')捕获资源加载失败；用navigator.onLine变化辅助判断是否处于离线状态 - 避免误判：401/403 等业务态错误不计入失败率（属于正常流程），但需单独打标便于后端分析；500/502/503 和超时、连接拒绝才计入失败指标
二、怎么统计失败率
失败率不是单次请求成败，而是有上下文的时间窗口指标。建议按「分钟级滑动窗口」+「采样控制」实现：
- 维护一个长度为 60 的数组，每分钟 push 当前分钟的失败请求数与总请求数（例如
[{fail: 2, total: 48}]） - 每 30 秒计算一次最近 5 分钟的失败率：
sum(fail) / sum(total)，若低于 0.5% 则跳过上报（降噪） - 对高频接口（如心跳、埋点）做独立统计桶，避免被低频高失败接口拉偏整体值
三、怎么安全可靠地上报
失败率本身是聚合指标，不带敏感数据，但上报机制必须健壮：
- 优先使用
navigator.sendBeacon发送，即使用户关闭页面也能发出（尤其适合记录“最后一次失败率突增”） - 上报 payload 示例：
{type:'api-failure-rate', value:0.082, window:'5m', timestamp:1725492840000, url:location.href, ua:navigator.userAgent} - 若 sendBeacon 不可用，退到
fetch(..., {keepalive: true})；仍失败则暂存localStorage，下次页面加载时补发（最多重试 2 次） - 禁止在上报中携带 request body、headers、token、用户 ID 等原始请求信息——只传脱敏指标和必要上下文
四、怎么联动定位问题
光有失败率数字没意义，要能快速下钻：
- 在失败率超标时，自动触发一次「快照上报」：采集最近 10 条失败请求的 URL、method、status、耗时、是否跨域、networkType（4g/wifi/unknown）
- 将失败率曲线与 CDN 状态、后端服务 P99 延迟、地区分布做关联展示（需后端配合）
- 支持按「接口路径正则」过滤统计，比如
/api/v2/order/.*单独看下单链路健康度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
