现代浏览器中autoplay在有声音频上无效是策略限制，需用户交互触发且每个audio实例须单独激活；根本原因是资源未加载，iOS和微信WebView要求显式load()，可靠方案是一次点击内同步完成所有音频的load()→play()→pause()。
现代浏览器里，autoplay 属性在有声音频上基本无效，这不是 bug，而是策略铁律——必须由用户真实交互触发，且每个 HTMLAudioElement 实例都要单独激活。
为什么 click 后调 play() 还失败？
常见现象是：按钮点了，audio.play() 返回 Promise，既不 resolve 也不 reject，audio.readyState 停在 0 或 1，audio.networkState 是 NETWORK_EMPTY。根本原因不是 JS 写错了，而是音频资源压根没加载。
- iOS 和微信 WebView 要求显式调用
load()才能进入可播放状态，仅靠play()不会触发下载 - 桌面 Chrome/Safari 虽可能“侥幸”播一次，但依赖资源是否已缓存或 preload 状态，不可靠
- 没监听
loadedmetadata就调play()，大概率被静默拒绝（尤其在低网速或大文件场景）
如何设计可靠的一次性用户交互链路？
核心目标：用**一次点击/触摸**，激活所有待用音频实例，后续任意逻辑调 play() 都能成功。不能只激活一个，也不能指望“激活过一次就全局生效”。
- 收集全部音频元素：
const audios = document.querySelectorAll('audio[data-role="bgm"], audio[data-role="sfx"]') - 绑定到首个可信事件（
click、touchstart、keydown），避免scroll或mousemove - 在事件回调中遍历执行：
audio.load()→audio.play().catch(() => {})→audio.pause() - 务必在
play()后立即pause()：既防止用户听到杂音，又保留已建立的播放上下文
iOS 和微信 WebView 的特殊处理要点
这两类环境比桌面更严，且行为不一致——不能写一套代码通吃。
立即学习“前端免费学习笔记（深入）”；
- iOS Safari：即使加了
muted="true"，首次播放仍需用户 touch 启动；解除静音后调play()仍可能被拒 - 微信 iOS WebView：
autoplay和muted全部忽略，必须等WeixinJSBridgeReady事件后再走预激活三步 - 每个音频元素必须独立预激活：播过
audio1≠audio2自动解锁，漏一个就卡住 - 禁止用
setTimeout或Promise.then延迟调play()：脱离原始事件栈即失效
真正容易被忽略的是：预激活必须在用户手势回调内同步完成，且每个 audio 实例都得走完 load()→play()→pause() 流程。少一步，后续就不可控；多一个没覆盖的实例，就等于埋了个静默失败点。
