iOS Safari和微信WebView要求每个audio元素必须在用户手势事件中单独执行load()→play()→pause()三步预热才能播放，muted可绕过限制但解除静音后需重新激活，loop属性不可靠应改用ended事件手动循环。
为什么audio.play()在iOS上总抛NotAllowedError
iOS Safari 和微信 WebView 对每个 HTMLAudioElement 实行“手势逐个激活”策略：哪怕你刚点过按钮播了 audio1，再调 audio2.play() 仍会失败。这不是 Promise 拒绝或报错，而是静默失效——play() 返回的 Promise 既不 resolve 也不 reject，readyState 卡在 0 或 1，networkState 为 0（NETWORK_EMPTY）。
根本原因不是资源没加载完，而是浏览器要求：**必须在用户手势事件回调内，对目标 audio 元素显式执行 load() → play() → pause() 三步预热**。缺一不可。
-
load()强制触发资源下载和解码准备，仅靠autoplay或play()不会触发 -
play()在手势上下文中才被允许建立播放上下文 -
pause()不是“暂停播放”，而是中断初始发声流（避免用户听到杂音），同时保留已激活的播放能力 - 不能用
setTimeout、Promise.then或事件委托间接触发——脱离原始事件栈即失效
微信环境里WeixinJSBridgeReady后仍无法play怎么办
微信内置浏览器有双重限制：既需用户手势，又依赖 WeixinJSBridgeReady 信号。但很多开发者误以为监听到该事件就能直接 play()，结果依然失败。
正确做法是：在 WeixinJSBridgeReady 回调中，**重复执行与用户手势相同的预热链路**，且要确保此时页面已可见、音频元素已挂载 DOM。
立即学习“前端免费学习笔记（深入）”；
- 先收集所有待用 audio：
const audios = document.querySelectorAll('audio[data-preload]') - 在
WeixinJSBridgeReady回调里遍历：audio.load(); audio.play().catch(() => {}); audio.pause(); - 若页面尚未完成首次交互（如用户还没点过任何地方），即使桥接就绪，
play()仍可能失败——此时应降级为等待首次点击后再执行 - 不要把
WeixinJSBridgeReady当作“全局解锁开关”，它只是微信环境的就绪信号，不替代手势激活
muted=true真能绕过自动播放限制吗
可以，但只适用于背景音效类场景，且有明确副作用：iOS 允许 muted 音频在 autoplay 或非手势上下文中播放，但一旦你后续设 audio.muted = false，再调 play() 仍会失败——解除静音 ≠ 重新激活。
- 必须同时写
<audio muted autoplay>，仅设volume="0"不生效 -
muted是布尔属性，muted=""和muted="muted"等价，推荐简写muted - 设
muted = false后立即play()，Safari 很可能立刻暂停；稳妥做法是放进微任务：setTimeout(() => { audio.muted = false; }, 10) - 桌面 Chrome 对
muted+autoplay支持较好；iOS Safari 有时仍要求用户至少一次触摸，不能完全依赖
loop属性为何在移动端循环不连贯
loop 属性在 iOS Safari 上基本不可靠：MP3 文件存在明显毫秒级静音间隙，WAV/OGG 稍好但仍有卡顿。这不是代码问题，而是解码器和播放管线的固有缺陷。
真正可控的循环，得放弃 loop，改用 ended 事件 + 手动 load() + play()，但必须确保用户已激活上下文。
-
loop是布尔属性，loop="true"或loop="loop"无效，只认是否声明 - JS 中赋值必须是布尔值：
audio.loop = true，而非字符串 - 在
ended里直接play()容易失败，尤其静音策略下；应先load()再play() - 加
try/catch并 fallback：audio.currentTime = 0; audio.play(); - 对“无缝”有硬需求的场景（如白噪音、伴奏循环），优先测
.ogg格式，MP3 尽量避免
