移动端H5音视频需用户手势触发播放，根本原因是浏览器策略限制；应监听touchstart/click事件立即调用play()，用静音视频预播放解锁音频，微信环境须结合JS-SDK ready状态，续播需重新获取手势授权。
移动端 H5 媒体（音频/视频）无法自动播放，根本原因不是代码写错了，而是浏览器策略强制要求：带声音的媒体必须由明确的用户手势触发。所谓“安全触发”，就是让 play() 调用落在合法的用户交互上下文中，不被拦截、不报错、不静音失效。
必须绑定真实、及时、一次性的用户手势
浏览器只认真实的 touchstart、click、tap 等原生事件，且必须在事件回调函数内部立即调用 play() —— 不能延时（setTimeout）、不能异步（Promise.then）、不能放在后续生命周期钩子中。
- 推荐监听 document.body 的 touchstart 或 click，并用
{ once: true }确保只响应首次交互 - 避免监听按钮点击后又做复杂逻辑再播放，中间任何延迟都会导致上下文丢失
- iOS Safari 和微信 iOS 环境对 touchstart 更敏感，Android X5 内核则 click/tap 均可，建议双事件兼容
优先使用静音视频预播放解锁音频能力
很多场景需要的是有声播放，但首次触发受限。一个稳定解法是：用一个 静音 video 元素 在用户第一次触摸时播放一帧，借此“激活”媒体上下文，之后再操作 audio 或有声 video 就能成功。
- 创建一个
元素，宽高设为 1×1 或 visibility: hidden - 在 touchstart 回调里调用
video.play()，无需等待 loadeddata，只要元素存在即可 - 播放后立即
video.pause()，不影响体验，但已解除播放锁 - 此时再调用 audio.play() 或有声 video.play()，成功率接近 100%
微信 H5 必须结合 JS-SDK ready 状态
在微信内置浏览器中，仅靠 DOM 事件还不够可靠。iOS 微信尤其依赖 WeixinJSBridge 就绪信号来确认页面处于可信上下文。
- 引入 jweixin-module（比官方 SDK 更适配 uni-app 和现代构建工具）
- 在
wx.ready回调内初始化 audio 实例，并执行首次play() - 不要在
wx.config成功后就立刻 play，必须等 ready；也不要跳过 config 直接用 WeixinJSBridgeReady 事件（兼容性差） - 若未接入 JS-SDK，至少需监听
window.WeixinJSBridgeReady事件作为兜底
续播和连播要当新请求处理
媒体 ended 后直接调 play() 一定会失败——浏览器不认为这是用户新授权，而是延续旧上下文。必须重新获取手势授权。
- 监听
@ended后，显示轻量提示（如底部浮动“继续播放”按钮），绑定 click 触发下一段 - 或监听 document 的下一次 touchstart，仅一次，立即播放下一轨，然后移除监听
- 复用同一 audio 实例，不要反复 destroy + createInnerAudioContext，否则容易触发策略重检
- 避免用
setTimeout(() => audio.play(), 0)，零延迟也不等于用户手势
