我之前在做移动端音频播放的时候也碰到过一模一样的坑！当时用loop=true或者onended事件手动循环，结果音频总是在结束前几秒就跳回开头，折腾了好一阵才找到几个可行的解决办法，结合你的移动端场景给你分享下：

可能的原因&对应解决方案 #

1. 音频文件元数据有误 #

很多时候是音频文件本身的时长元数据不准确导致的——浏览器读取的时长比实际音频长度短，所以会提前触发循环。

• 解决办法：用音频编辑工具（比如Audacity）重新导出音频，导出时勾选“写入准确的元数据”选项，确保文件的时长信息正确。

2. 替换loop属性，用更严谨的onended逻辑 #

原生的loop属性在不同浏览器（尤其是移动端）的行为不太一致，换成手动控制循环时，加个判断确保确实播放到了音频末尾：

s.onended = function() {
  // 允许0.1秒的误差，避免因精度问题提前触发
  if (Math.abs(this.duration - this.currentTime) < 0.1) {
    this.currentTime = 0;
    // 移动端可能需要重新触发播放（比如用户交互限制）
    this.play().catch(err => console.log('播放失败:', err));
  }
};

另外要注意移动端的自动播放限制，确保第一次播放是由用户交互触发的，后续循环才能正常执行。

3. 等待音频完全加载后再播放 #

如果音频没完全加载，浏览器可能会用预估的时长来计算，导致提前循环。可以监听canplaythrough事件，确保音频可以完整播放后再启动：

s.addEventListener('canplaythrough', function() {
  // 这里再开始播放，保证时长计算准确
  this.play();
});
// 别忘了设置预加载
s.preload = 'auto';

4. 监听timeupdate做兜底处理 #

如果上面的方法还是有问题，可以监听timeupdate事件，当播放进度接近真实时长时手动触发循环：

s.addEventListener('timeupdate', function() {
  // 当播放到离末尾还有0.5秒时，强制跳回开头
  if (this.currentTime >= this.duration - 0.5) {
    this.currentTime = 0;
    this.play();
  }
});

这个方法虽然有点“粗暴”，但在某些元数据异常的场景下特别管用。

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