ios audio autoplay无效且play()抛notallowederror，因需用户手势激活每个audio元素；须在touchstart等事件中依次调load()、play()、pause()预热，微信环境还需监听weixinjsbridgeready并兜底处理。
iOS上audio标签的autoplay属性基本无效，直接调用play()也会抛出NotAllowedError——这不是bug，是Safari和微信内置浏览器的强制策略。关键不是“怎么让它播”，而是“怎么在用户第一次点/触之后，让后续所有播放都可控”。
为什么play()在iOS里突然失败？
iOS要求每个HTMLAudioElement必须先被“用户手势激活”，否则play()调用会被静默拒绝（Promise reject，不抛异常但也不生效）。这个激活不是一次性的全局开关，而是按元素独立计算的：哪怕你刚点过按钮播了audio1，再调audio2.play()仍会失败。
常见错误现象包括：
-
audio.play()返回Promise，但既不resolve也不reject，控制台也无报错 -
audio.readyState卡在0或1，networkState为0（NETWORK_EMPTY） - 微信内嵌页中
WeixinJSBridgeReady触发后调play()仍无效
必须在用户手势回调里调load() + play() + pause()
iOS 9+ 要求音频资源必须显式load()才能进入可播放状态；仅靠play()无法触发下载。而pause()的作用不是“暂停播放”，是中断初始播放流、避免用户听到杂音，同时保留已建立的播放上下文。
实操建议：
- 把所有待用的
audio元素提前收集到数组，比如const audios = document.querySelectorAll('audio[data-preload]') - 在
click、touchstart等事件回调中遍历执行：audio.load(); audio.play().catch(() => {}); audio.pause(); - 不要用
setTimeout或Promise.then包裹play()——脱离原始事件栈即失效 - 微信环境需额外监听
WeixinJSBridgeReady，并在其回调里重复上述三步
muted=true能绕过限制吗？
可以，但只适用于背景音乐类场景，且有副作用：iOS允许muted音频在autoplay或非手势上下文中播放，但一旦你后续设audio.muted = false，再调play()仍会失败——解除静音不等于重新激活。
更稳妥的做法是：
- 页面加载时就设
<audio muted preload="auto"></audio> - 首次交互时调
play()（此时静音，无声音） - 后续需要发声时，先
audio.muted = false，再audio.play()（因已激活，这次会响）
注意：Android和桌面Chrome对muted策略宽松，但iOS Safari和微信WebView严格依赖这个链路。
微信内H5必须处理WeixinJSBridgeReady + 触摸兜底
微信iOS端有双重限制：既遵循Safari媒体策略，又在某些版本中延迟暴露WeixinJSBridge。单纯监听WeixinJSBridgeReady可能错过时机；只靠touchstart又可能被微信拦截（尤其iOS 16+）。
推荐组合写法：
- 页面加载完成时立即注册
WeixinJSBridgeReady监听，并在回调中激活所有audio - 同时绑定
document.addEventListener('touchstart', handler, { once: true })作为 fallback - handler里检查
audio.readyState >= 2，若未就绪则先load()再play()/pause()
最容易被忽略的一点：iOS上audio元素的src必须是绝对路径或同域相对路径，动态拼接的src（如audio.src = './sound.mp3'）在微信里常因CORS或协议问题导致networkState === 0，这时load()也无效——务必在HTML里写死src或用fetch()预取后赋值blob URL。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
