网页音乐播放器无法直接捕获网络中断错误，需通过stalled、error、suspend等事件组合判断异常，连续多次stalled是网络卡顿最直接信号。
网页音乐播放器无法直接“捕获网络中断错误”并自动重连，因为 HTML5 <audio> 标签本身不暴露底层连接状态或协议栈错误（如 TCP 断开、DNS 失败、CDN 返回 404/503）。但它会通过一系列可监听的事件和异常行为间接反映问题，关键在于识别这些信号，并主动干预。
监听关键事件组合判断流异常
仅靠 error 事件远远不够——它常被静音、策略拦截、解码失败等干扰。需结合多个信号交叉验证：
-
监听
stalled事件：表示浏览器尝试加载但长时间无数据到达，是网络卡顿最直接的信号。连续触发 2–3 次（间隔 -
监听
waiting+ 长时间无playing：若进入waiting后超过 5 秒仍未恢复playing，大概率缓冲失败。 -
检查
networkState值：在stalled或waiting时读取audio.networkState，若为0（NETWORK_EMPTY）或1（NETWORK_IDLE）且持续超时，说明未建立有效连接。 -
捕获
play().catch()拒绝：用户手势后首次播放失败，或ended后重播失败，常因资源不可达或 CORS 被拒，需记录错误信息（err.name和err.message）。
触发重连前先清理与重置
盲目调 load() 或 src = src 可能无效，必须清除旧上下文：
- 调用
audio.pause()并设audio.currentTime = 0，避免残留缓冲干扰。 - 执行
audio.src = ''清空当前源，再赋新值（即使相同 URL），强制重建加载流程。 - 如有必要，移除并重新绑定
stalled/error监听器，防止重复注册。
实现带退避的重试逻辑
重连不是立即重试，需避免雪崩式请求：
- 首次失败后等待 2 秒 再尝试；第二次失败延至 4 秒；第三次 8 秒；最多不超过 5 次。
- 每次重试前检查
navigator.onLine，若为false暂停重试，监听online事件恢复。 - 重试时可切换备用音频 URL（如主 CDN 失败切备用域名），需提前配置 fallback 列表。
补充：服务端配合更可靠
纯前端判断有局限。建议后端音频服务返回标准 HTTP 状态码（如 503 表示临时不可用），并在响应头中添加 X-Retry-After: 5，前端解析该字段控制重试间隔，比固定退避更精准。
