现代浏览器对audio播放的限制是策略强制而非兼容性差，核心要求是必须带正确type（如audio/mpeg），且首次有声播放须由用户手势触发。
现代浏览器对 audio 的播放限制不是“兼容性差”，而是策略强制——不按规则写，再全的格式 fallback 也白搭。真正起效的兼容策略，核心就两条：<source></source> 必须带正确 type，且首次有声播放必须由用户手势触发。
为什么只写 src 属性在 Safari/iOS 上直接静默失败
浏览器不会解析 MP3 文件头去猜编码，它只认 type 值是否匹配 MIME 类型。省略 type 时，Chrome 可能碰巧加载成功，但 iOS Safari 会跳过整个 <source></source>，导致 canplay 不触发、duration 为 NaN、控制台也不报错。
-
<source src="a.mp3"></source>→ iOS Safari 直接忽略，音频不可用 -
<source src="a.mp3" type="audio/mp3"></source>→ 错误写法，type必须是audio/mpeg - 正确写法：
<source src="a.mp3" type="audio/mpeg"></source>+<source src="a.ogg" type="audio/ogg"></source> - Ogg 文件需确认是 Vorbis 编码（
ffprobe a.ogg查看输出含Audio: vorbis）
为什么加了 autoplay muted 还没声音
写了 autoplay muted 却没声音，不是代码问题，是浏览器在等用户“动手”。桌面 Chrome/Firefox 通常能静音自动播；但 iOS Safari 和微信 WebView 要求更严：即使 muted，首次 play() 仍需用户真实触发（如 click 或 touchstart），否则 Promise 被 reject，错误信息为 DOMException: play() failed because the user didn't interact with the document first。
- 不要把
play()放在DOMContentLoaded或window.onload里 - iOS 要求元素在视口内、未被
display: none或opacity: 0遮挡 - 微信 iOS WebView 必须等
WeixinJSBridgeReady事件后再调play() - 每个
audio实例都要单独预激活：用户首次交互后，对每个元素执行一次play().then(() => pause())
如何让按钮点击真正触发播放（而非点两次才生效）
移动端点一次没反应，本质是事件未被识别为“可信用户手势”。原生 <button></button> 是最稳妥的绑定目标；若用 <div>，必须加 <code>role="button" 并确保事件冒泡未被中途 stopPropagation() 拦截。
-
play()必须在点击回调中同步调用，不能包在setTimeout里（iOS 会判为非用户驱动） - 先监听
loadedmetadata或canplay，再绑定点击逻辑，避免资源未就绪导致静默失败 - 务必
.catch(e => console.warn('play blocked:', e))，区分是策略拦截还是路径/格式问题 - 按钮状态更新要依赖
audio.paused属性和play/pause事件，不能只靠 JS 变量记录
最容易被忽略的是：iOS 对每个 audio 元素单独校验用户手势上下文。漏掉任意一个没预激活，它后续任何时机调 play() 都会失败——哪怕其他音频已正常播放。
