ios safari点击后play()仍失败，因其仅认button或role="button"+tabindex="0"元素的同步click事件，且必须在回调首层直接调用；autoplay+muted在ios无效，首次播放仍需用户手势触发。
移动端 HTML 音频播放失败，八成不是代码写错，而是被 iOS Safari 或 Android Chrome 的自动播放策略拦截了——play() 调用没报错，但就是不响，连控制台都安静如鸡。
为什么 iOS Safari 点击后 play() 仍失败
iOS Safari 要求所有带声音的 play() 必须发生在「可信用户手势」上下文中：不能是 setTimeout 延迟调用、不能是 Promise.then 里触发、不能绑定在没语义的 <div> 上（即使加了 <code>onclick）。它只认原生 <button></button>、<a></a> 或明确设了 role="button" + tabindex="0" 的元素的同步点击事件。
- 确保按钮是
<button></button>标签，或至少有role="button" tabindex="0" - 事件监听必须用
addEventListener('click', ...)，不要用内联onclick="" -
play()调用必须在事件回调第一层直接执行，不能包在异步函数或定时器里 - 首次播放后，后续
play()才可能脱离手势上下文（iOS 15+ 放宽，但别依赖）
autoplay 和 muted 组合为何有时也不生效
Chrome/Edge/Firefox 允许 autoplay muted 自动播放，但 iOS Safari 不买账：它把 muted 视为“暂时静音”，而非“无声音意图”，仍要求用户手势才能解锁音频上下文。所以即使写了 autoplay muted，iOS 上首次 play() 还是得点一下。
- 移动端不要指望
autoplay真正自动响，它只对静音视频有效 -
muted的作用是绕过「有声自动播放」拦截，不是让音频变静音后就能播 - 若需静音启动再手动取消静音，必须先成功
play()一次，再改audio.muted = false
安卓 WebView 中 play() 报 DOMException: The element has no supported sources
这不是路径问题，而是 WebView 默认禁用媒体加载——尤其在 Android 7–10 的系统 WebView 或旧版 Cordova 中。即使 src 正确、<source></source> 带了 type，也会因 MIME 类型未注册而拒绝解析。
- 确保
<source></source>标签显式声明type="audio/mpeg"（MP3）、type="audio/ogg"（OGG）等，不能省略 - 避免用相对路径如
./bgm.mp3，改用绝对路径或file:///android_asset/（原生打包场景） - 在 WebView 初始化时启用 JavaScript 和媒体支持：
webview.getSettings().setMediaPlaybackRequiresUserGesture(false)（仅调试用，上线前关掉）
预加载与首帧延迟的取舍：该用 preload="metadata" 还是 "none"
preload="auto" 在移动端等于自找麻烦：WiFi 下还好，4G/5G 弱网时整首 MP3 下载一半卡住，canplay 事件永远不触发，按钮点了也白点。而 preload="metadata" 只拉时长和采样率，快且省流量，但有个隐藏代价：iOS Safari 会因此跳过音频解码准备，导致首次 play() 有 200–400ms 延迟（尤其大文件）。
- 背景音乐类小文件（preload="metadata"，平衡速度与体验
- 音效类极小文件（preload="auto" 或直接 new Audio() 预实例化，换掉延迟
- 用户明确要播才加载的场景（如文章内嵌音频）：用
preload="none"，点按钮时再设src并load()
最常被忽略的一点：iOS Safari 对 controlsList 的支持直到 iOS 16.4 才稳定，之前版本设了 nodownload 也没用；而 Android Chrome 对 preload 的解释又和桌面版不一致——这些差异没法靠统一配置抹平，得靠 UA 检测 + 条件加载逻辑兜底。
