iOS微信小程序中uni.createInnerAudioContext().loop=true无效，存在100–300ms播放间隙，需手动监听onEnded执行seek(0)并play()，且须等onCanplay后操作、使用HTTPS音频URL、调用wx.setInnerAudioOption({obeyMuteSwitch:false})绕过静音开关，并复用单实例避免频繁创建。
uni.createInnerAudioContext().loop = true 在小程序端无效
设 loop = true 后，iOS 微信和部分安卓微信真机仍会出现 100–300ms 的播放间隙，用户能明显感知“卡顿”或“停顿”。这不是 bug，而是 iOS 系统级限制——它不支持真正无缝循环，loop 属性仅作提示，底层不会自动 seek 到开头重播。
正确做法是手动监听 onEnded 并触发重播逻辑：
audio.onEnded(() => { audio.seek(0); audio.play(); })-
seek(0)在部分 Android 机型（如旧版华为、OPPO）可能失败，建议包裹try/catch，失败时 fallback 为重新赋值src - 避免在
onLoad或onShow中立即调用seek()，需等onCanplay触发后再操作，否则seek会静默失败
微信小程序端必须用网络音频 URL，本地路径大概率静音
iOS 微信对本地音频文件（如 /static/bg.mp3）的加载策略极不稳定，尤其 iPhone X 及以上机型常报错或无声；而换成合法 HTTPS URL（如 https://cdn.example.com/bg.mp3）后基本可稳定播放。
原因在于微信 WebView 对本地资源的解码权限受限，且不统一处理静音开关逻辑。解决方案很直接：
- 所有音频文件上传到 CDN 或自有 HTTPS 服务器
- 确保服务端返回
Content-Type: audio/mpeg，避免被识别为text/plain - 域名需在微信小程序后台「开发管理 → 域名配置」中白名单备案，否则请求直接被拦截
静音开关导致无声？必须调用 wx.setInnerAudioOption
即使用户没开静音，iPhone 侧边物理静音开关默认会压制 uni.createInnerAudioContext() 播放——这是 iOS 微信特有行为，H5 和 App 端不受影响。
唯一绕过方式是提前调用微信原生 API：
- 仅限微信平台，需用
#ifdef MP-WEIXIN包裹 - 在
play()前执行wx.setInnerAudioOption({ obeyMuteSwitch: false }) - 该调用无返回值，也不抛错，失败时静默忽略——务必真机测试确认是否生效
- 注意：此 API 不兼容支付宝/百度小程序，跨平台项目需条件编译隔离
循环播放时频繁创建实例会导致卡顿或静音
每次循环都新建 uni.createInnerAudioContext() 实例，安卓端极易引发内存堆积、卡顿甚至后续播放完全失效（表现为 errCode -99 或无任何日志）。
推荐复用单实例 + 清理状态：
- 全局或页面级只持有一个
audio实例，不要在onEnded里重复createInnerAudioContext() - 每次循环前调用
audio.stop()再seek(0)，而非销毁重建 - 监听
onError，捕获errCode: 10004（资源加载失败）或-99（解码失败），失败时才重建实例 - 避免在快速连续点击按钮时触发多次
play()，加个isPlaying标志位防抖
