ios safari要求audio.play()必须在用户手势事件同步链中执行，异步调用（如settimeout、canplay后触发）均失败；须在click/touchstart回调内直接调用play().catch()，且元素需在视口内可见。
为什么 iOS Safari 上 audio.play() 总是报错
不是代码写错了，是浏览器根本没给执行权限。iOS WebKit 要求所有 play() 必须发生在用户手势（click、touchstart）的同步调用链中，异步延迟哪怕 1ms 都会失败。
常见错误现象：
- 在
setTimeout(() => audio.play(), 0)里调用 → 报DOMException: play() failed because the user didn't interact with the document first - 监听
canplay后自动play()→ 静默失败，控制台无提示，duration可能还是NaN - 按钮点击后又发请求、等数据回来再
play()→ 已脱离手势上下文，100% 被拒
实操建议：
- 把
audio.play().catch(e => console.warn("play blocked:", e))直接写在事件回调最内层，不加任何异步包装 - iOS 还要求元素必须在视口内、未被
display: none或opacity: 0遮挡，否则即使点了也无效 - 首次交互后，可缓存这个“授权状态”，后续
play()就不再受限（但页面刷新即失效）
如何让 MP3 在 Firefox 和 Safari 同时播放
单写 <audio src="a.mp3"></audio> 是赌运气：Firefox 不认 MP3，Safari 不认 OGG，只靠一个格式永远有盲区。
必须用 <source></source> 多源兜底，且 type 值不能手写错：
-
type="audio/mp3"❌ 错误，标准 MIME 是audio/mpeg -
type="audio/ogg"✅ 正确，但 OGG 文件必须是 Vorbis 编码（不是 Opus），可用ffprobe a.ogg确认 - WAV 不推荐：Chrome 对 IEEE Float 编码直接拒绝，文件体积大，加载慢
正确写法示例：
<audio controls><source src="a.mp3" type="audio/mpeg"><source src="a.ogg" type="audio/ogg"> 您的浏览器不支持 audio 元素。 </source></source></audio>
注意：服务器响应头里的 Content-Type 必须与 type 严格匹配，否则 Safari 会跳过该源。Nginx 需加 audio/mpeg mp3;，Apache 需加 AddType audio/mpeg .mp3。
preload="auto" 在移动端有没有用
基本没用，尤其对 iOS Safari —— 它会直接忽略 preload="auto"，且可能因预加载触发网络策略拦截或耗用户流量。
实操建议：
- 统一设为
preload="metadata"：只加载时长、采样率等元信息，不拉音频体，首帧快、兼容稳 - 别指望靠
preload绕过用户手势限制；它解决不了play()被拒问题 - 安卓低版本 WebView 对
preload支持混乱，有些根本不触发loadedmetadata，不如不用
真正影响首播速度的是资源路径有效性、CDN 缓存命中率和服务器 MIME 配置，不是这个属性。
为什么 new Audio() 在 iOS 上开多个实例很危险
iOS WebKit 对每个 new Audio() 实例都分配独立解码线程，频繁创建销毁会导致内存泄漏、卡顿，甚至页面崩溃。
实操建议：
- 全局只维护一个
Audio实例，通过切换src播放不同音频，而不是每次new Audio(src) - 首次用户交互时（如
touchstart）立即初始化这个实例并暂存到window.audioPool，避免后续play()因实例未就绪而失败 - 切换
src后需监听canplay再play()，iOS 不允许在未就绪前设置currentTime或调用play()
这个点容易被忽略：很多人以为“只是多建个对象”，实际在 iOS 上它直接关联底层音频资源调度，不是 JS 层面的轻量操作。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
