Safari修改音频源后直接调用play触发DOMError AbortError问题求助

我最近也留意到Safari在去年12月左右的更新里引入了这个让人摸不着头脑的问题——当你修改音频元素的src后立刻调用play()，会触发DOMError导致Promise被拒绝，但实际音频却能正常播放。这个情况确实只在Safari里出现，挺折腾人的。

可能的原因 #

推测这是Safari媒体加载模块的一个小bug：修改src后，浏览器需要时间更新媒体元素的内部状态（比如切换加载上下文、初始化解码器），如果在这个状态过渡的间隙调用play()，浏览器的Promise校验逻辑会误判操作无效，抛出中止错误，但底层的播放流程已经被触发，所以音频还是能正常播放。

正确的解决方式 #

最稳妥的做法是等待媒体元素进入稳定的可播放状态后再调用play()，推荐使用以下标准事件之一：

1. 监听loadeddata事件 #

这个事件触发时，音频的第一帧已经加载完成，元素状态完全稳定，此时调用play()不会触发错误：

const audio = document.getElementById('your-audio-element');
audio.src = 'new-audio-source.mp3';

// 用once: true确保事件只触发一次，避免重复绑定
audio.addEventListener('loadeddata', async () => {
  try {
    await audio.play();
    console.log('音频播放启动成功');
  } catch (err) {
    // 这里的错误才是真正的播放失败，比如用户未交互导致的自动播放限制
    console.error('播放失败:', err);
  }
}, { once: true });

2. 监听canplay事件 #

如果不需要等待第一帧完全加载，canplay事件表示媒体已经积累了足够的数据可以开始播放，也能解决这个问题：

audio.addEventListener('canplay', async () => {
  try {
    await audio.play();
  } catch (err) {
    console.error('播放失败:', err);
  }
}, { once: true });

关于临时等待方案的弊端 #

你提到的调用play()前用setTimeout稍作等待确实能临时解决，但这种方案很不可靠：不同设备的网络速度、硬件性能差异很大，设置的等待时间在快设备上是浪费，在慢设备上可能还是不够，容易出现偶发问题，不推荐作为长期解决方案。

额外注意事项 #

• 如果你的音频是跨域资源，要确保服务器配置了正确的CORS响应头，否则可能会触发其他媒体加载相关的错误，干扰问题排查。
• 如果你频繁切换音频源，记得清理之前的事件监听（使用{ once: true }可以自动避免这个问题），防止内存泄漏或重复触发。

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