网页音乐播放器无法直接捕获网络中断错误，需通过stalled、error、suspend等事件组合判断异常，连续多次stalled是网络卡顿最直接信号。

网页音乐播放器无法直接“捕获网络中断错误”并自动重连，因为 HTML5 <audio></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 可能无效，必须清除旧上下文：

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

• 调用 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，前端解析该字段控制重试间隔，比固定退避更精准。