play函数不处理断网重连，需监听error、stalled、suspend事件组合，通过load()或重设src重置加载，并采用指数退避重试，且重连后需用户交互才能恢复播放。
play 函数本身不处理断网重连
play 是媒体播放的触发动作，比如 audio.play() 或 video.play()，它只负责发起播放请求，不感知网络状态，也不内置重试逻辑。一旦底层资源加载失败（比如因断网导致 networkState 变为 NETWORK_NO_SOURCE 或触发 error 事件），play 就会直接拒绝或静默失败——尤其在自动播放策略收紧的现代浏览器中，常见报错是 DOMException: The element has no supported sources 或 AbortError。
真正要解决断线重连，得绕开 play 本身，转而监控媒体元素状态、拦截错误、主动恢复加载流程。
监听 error + stalled + suspend 三个关键事件
仅靠 error 不够：网络抖动时可能不抛错，而是卡在加载中（stalled）或被浏览器主动挂起（suspend）。这三个事件组合才能覆盖大部分中断场景：
-
error：资源彻底加载失败，media.error有具体码（如MEDIA_ERR_NETWORK） -
stalled：浏览器尝试拉取数据但长时间无响应（通常 > 1s），说明连接可能已断 -
suspend：资源加载被中止（比如用户切到其他 tab，或网络临时不可用）
实操建议：
– 给 audio/video 元素统一绑定这三类事件
– 每次触发时记录时间戳，避免重复触发重试
– 不要在 stalled 中立即重载，先等 500ms 再判断 networkState === NETWORK_NO_SOURCE 或 readyState === 0
重连时不要直接调用 play()，先 reload() 或重设 src
直接 element.play() 在中断后大概率失败，因为内部加载器已处于异常状态。必须重置加载流程：
- 如果用的是流式地址（如 HLS/DASH），优先调用
element.load()，它会清空当前缓冲并重新开始加载 - 如果是普通 MP3/MP4 地址，可改写
src（哪怕赋相同值）再load()，强制刷新加载器：element.src = element.src;<br>element.load();
- 注意：Safari 对
load()后立刻play()敏感，建议加setTimeout(() => element.play(), 10)避免被策略拦截
自动重试要带退避策略和最大次数限制
无脑轮询重试会加重服务器压力，也容易触发浏览器限流（如 Chrome 对同一资源连续失败 3 次后会延长加载间隔）：
- 首次失败后延迟 1s 重试，第二次延迟 2s，第三次 4s（指数退避）
- 超过 3 次失败就停手，改发用户提示（比如显示“正在重连…” → “连接不稳定，请检查网络”）
- 若使用
fetch+MediaSource手动加载，可在fetch层做重试；但原生audio/video标签只能靠事件驱动重载，无法干预底层 TCP 重连
最易被忽略的一点：重连成功后，play() 可能仍被静音策略阻止——必须确保用户有过交互（如点击过页面），否则 iOS Safari 和新版 Chrome 会直接拒绝播放。别指望后台自动恢复声音。
