ios safari和微信webview中audio需用户手势触发且每个实例独立预热：用或role="button"监听click，同步调play()；多音频须逐一load→play→pause；微信需weixinjsbridgeready后执行；muted=true仅限静音初播，解静音后需再调play()。
苹果设备（iOS Safari、微信 WebView）上 audio 标签无法播放，不是代码写错，而是浏览器策略强制拦截——play() 必须发生在用户真实手势上下文中，且每个 audio 元素需独立激活。绕开它不现实，但能稳稳“接住”限制。
为什么点按钮后 play() 还是没声音？
iOS Safari 只认原生 <button></button> 或带 role="button" tabindex="0" 的元素的同步 click 或 touchstart 事件；用 <div onclick="...">、<code>setTimeout 包一层、或在 canplay 回调里调 play()，全都会静默失败。
- 确保触发元素是
<button></button>，或至少含role="button" tabindex="0" - 监听必须用
addEventListener('click', ...)，不能内联onclick -
audio.play()要直接写在回调函数第一层，不进异步、不进 Promise 链 - 加
.catch(e => console.warn('play blocked:', e))，否则失败无声无提示
多个音频实例怎么一次性激活？
iOS 不共享播放权限：播过 audio1 ≠ audio2 就能播。每个待用的 audio 必须单独走一遍 load() → play() → pause()，才算“预热成功”。
- 收集所有目标
audio：const audios = document.querySelectorAll('audio[data-preload]') - 在首次点击/触摸回调中遍历执行：
audio.load(); audio.play().catch(() => {}); audio.pause(); -
load()不可省——iOS 9+ 要求显式加载才进入可播放状态 -
pause()不是为了“暂停”，是中断初始播放流、保留已建立的上下文
微信环境额外要等 WeixinJSBridgeReady 吗？
要。微信 WebView 对用户手势上下文校验更严，即使页面已响应点击，若 WeixinJSBridgeReady 未触发，预热三步仍可能无效。
- 在点击回调里加兜底判断：
if (typeof WeixinJSBridge !== 'undefined') { /* 执行预热 */ } else { document.addEventListener('WeixinJSBridgeReady', () => { /* 执行预热 */ }) } - 别只等一次：部分低版本微信可能触发多次，建议用
once: true或手动移除监听 - 预热必须在
WeixinJSBridgeReady触发后的同一事件栈内完成，不能延迟
muted="true" 真的能绕过限制吗？
能，但只限静音场景，且解除静音后不会自动恢复权限——这是最常被误用的一环。
- Chrome/Firefox 允许
muted+autoplay自动播放；iOS Safari 仍要求首次交互才能解锁上下文 - 正确链路是：
audio.muted = true→ 用户点击 →audio.play()成功 →audio.muted = false→ 再次audio.play() - 千万别在首次
play()前设muted = false，也别指望muted = true后再改回来就能播 - 本地开发用
file://协议时，连muted播放都会被 Chrome 拦截，必须起 HTTP 服务（如python3 -m http.server）
真正卡住人的不是“怎么播”，而是每个 audio 实例都得单独预热、微信要等桥接就绪、解除静音不等于重获权限——这些细节漏掉一个，就会在真机上完全无声，且控制台不报错。
