如何判断HTML5 Audio对象已完成媒体加载？Web音乐播放器预加载场景的技术问询

你遇到的这个预加载时机问题确实很典型——既要避免过早触发下一首转码拖慢当前播放，又要防止太晚导致曲目间出现讨厌的间隙。结合你试过的几种方案，我来分享一套更精准的判断逻辑，完美适配你的后端转码场景：

精准判断媒体完全加载的组合策略 #

其实没有单一事件或属性能直接告诉你“媒体已100%加载完成”，但我们可以通过组合多个状态和事件来精准卡点：

1. 结合progress事件与buffered属性（核心方案） #

progress事件会在浏览器加载媒体数据时持续触发，我们可以在这个事件里检查buffered对象的缓冲范围，直接判断是否已经加载完全：

audio.addEventListener('progress', () => {
  if (!audio.duration) return; // 先确保总时长已正确获取
  // 获取已缓冲的最后一个时间点
  const bufferedEnd = audio.buffered.end(audio.buffered.length - 1);
  // 当已缓冲时长接近总时长（留0.1秒容错），且音频已经开始播放
  if (bufferedEnd >= audio.duration - 0.1 && audio.currentTime > 0) {
    // 这里就是媒体完全加载完成的时机，启动下一首预加载
    preloadNextTrack();
    // 移除监听，避免重复触发
    audio.removeEventListener('progress', arguments.callee);
  }
});

• 为什么减0.1？有些浏览器的bufferedEnd会因为浮点精度问题，比实际duration略小一点，留个小容错空间更稳妥。
• 加上audio.currentTime > 0的判断，确保是在当前曲目已经开始播放之后才触发，完全符合你“第一首播放结束前、完成加载后”的需求。

2. 优化suspend事件的判断逻辑（补充验证） #

你当前用的suspend事件思路是对的——这个事件会在浏览器暂停加载媒体数据时触发，通常是因为已经加载了足够的数据（或者加载完成）。但可以优化判断条件，避免误触发：

audio.addEventListener('suspend', () => {
  if (!audio.duration) return;
  const bufferedEnd = audio.buffered.end(audio.buffered.length - 1);
  // 确认已缓冲完成，且当前处于播放状态（避免用户暂停时误触发）
  if (bufferedEnd >= audio.duration - 0.1 && audio.currentTime > 0 && !audio.paused) {
    preloadNextTrack();
    audio.removeEventListener('suspend', arguments.callee);
  }
});

3. 兜底方案：timeupdate事件的最后检查 #

如果上面的事件都没触发（比如网络异常导致加载断断续续），可以在当前曲目接近结束时（比如剩下5秒）做最后检查，确保不会错过预加载时机：

audio.addEventListener('timeupdate', () => {
  if (!audio.duration) return;
  // 当剩下5秒播放时长，且已缓冲完成
  if (audio.duration - audio.currentTime <= 5 && audio.buffered.end(audio.buffered.length - 1) >= audio.duration - 0.1) {
    preloadNextTrack();
    audio.removeEventListener('timeupdate', arguments.callee);
  }
});

复盘：为什么之前的方案不够理想？ #

再帮你梳理一下之前尝试的方案问题：

• canplaythrough：浏览器是基于当前网络速度预测能无缓冲播放，并不是真正加载完成，此时启动下一首转码会抢占带宽，直接导致预测失效、播放卡顿。
• networkState === NETWORK_IDLE：这个状态不仅在加载完成时触发，当浏览器觉得缓冲区足够支撑播放时也会暂停加载，所以会提前触发，不符合你的需求。
• duration属性：不同浏览器的实现差异极大，Firefox会逐步更新时长，Chrome可能因为CORS或媒体格式问题不返回准确值，完全不可靠。
• readyState：和canplay/canplaythrough对应，同样是基于缓冲预测的状态，不是加载完成的标志。

总结 #

最优的做法是同时组合progress事件的buffered检查 + suspend事件的二次验证，再加上timeupdate的兜底逻辑。这套组合既能精准捕捉到媒体完全加载的时机，又能避免误触发，完美适配你的后端转码场景——既不会过早启动下一首转码拖慢当前播放，也不会太晚导致曲目间隙。

内容的提问来源于stack exchange，提问作者Mark Smith