h5端音频无法自动重播是因浏览器策略限制，重播仍需用户交互触发；loop属性仅对播放中生效，结束后失效；可靠方案是绑定重播操作到显式用户点击或touchstart事件。
uni-app H5端音频无法自动重播的常见报错
直接调用 audioContext.play() 失败，控制台常出现 DOMException: play() failed because the user didn't interact with the document first 或静默失败（无报错但无声）。这不是代码写错了，而是浏览器策略在起作用：**重播也属于“播放”，同样受用户交互限制约束**。哪怕第一次已成功播放过，第二次调用 play() 时若中间没有新的用户手势（如点击、touchstart），iOS Safari 和微信 iOS 内核仍会拒绝执行。
为什么 loop=true 不起作用
loop 属性只对「正在播放中」的音频生效；一旦播放自然结束或被中断（比如页面切后台、用户手动暂停），音频上下文就进入 paused 状态，此时 loop 不再触发重播。更关键的是：H5 环境下，loop=true 无法绕过“需用户交互才能启动播放”的底层限制——它只是告诉引擎“播放完后自动从头开始”，但“开始”这个动作本身仍需合法触发。
-
loop在 iOS 微信中基本无效，即使设置为true，播放结束后也不会自动重播 - Android 微信 X5 内核对
loop支持略好，但依赖首次播放是否由用户触发，且不稳定 - 使用
onEnded回调里再次调用play()会失败，因为回调不属于用户手势上下文
真正可行的重播方案：绑定到用户操作 + 手动 reset
不要指望靠属性或事件自动重播，必须把“重播”动作显式绑定到一次新的用户交互，并在该交互中重置音频状态。核心逻辑是：播放结束 → 清除旧实例 → 创建新实例（或复用但重置 src）→ 绑定到 click/touchstart。
- 避免在
onEnded中调用play()，改用按钮显式触发重播 - 如果要用“自动重播”体验，可在
onEnded里显示一个透明覆盖层或小图标，引导用户轻点一下，点击后执行audioContext.seek(0); audioContext.play(); - 复用实例时务必先调用
audioContext.stop()或audioContext.pause()，再seek(0)，否则某些 Android 浏览器会卡在末尾 - 路径必须是网络地址（
https://xxx.mp3），/static/xxx.mp3在部分 iOS 微信中加载失败，导致重播时src为空
微信环境下的特殊处理：jweixin-module 不解决重播问题
引入 jweixin-module 并调用 wx.ready 只能帮你绕过“首次自动播放”的限制，它**不赋予你后续任意时刻调用 play() 的权限**。也就是说：wx.ready 里的 play() 只能执行一次（且必须在 ready 回调内），之后所有重播仍要遵守用户交互规则。
- 不要在
wx.ready里写循环逻辑或定时重播，无效 -
weixinJSBridge的ready事件也无法突破重播限制，它和wx.ready是同一机制 - 真要“伪自动”，可监听
document.ontouchstart（仅限首次），但 iOS 15+ 已限制该事件触发时机，不可靠
