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;
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 会直接拒绝播放。别指望后台自动恢复声音。










