因为每次调用uni.createInnerAudioContext()都创建独立实例，页面卸载后实例被回收，新页面获取的是全新对象，无法跨页面共享状态或控制，易致重叠播放、pause失效等问题。
为什么 uni.createInnerAudioContext() 不能直接全局复用
因为每次调用 uni.createInnerAudioContext() 都会创建一个全新实例，彼此隔离。你无法靠“保存一个实例变量”来实现跨页面控制——页面卸载后实例可能被回收，新页面里拿到的还是新对象。
常见错误现象：在 A 页面播放音频，跳转到 B 页面后调用 pause() 失效；或者多个页面各自 new 一个 context，导致声音重叠、状态混乱。
- 每个
InnerAudioContext实例只对自身生命周期负责，不共享状态 - 小程序容器不提供跨页面音频句柄传递机制（
getCurrentInstance()在 onUnload 后失效） - H5 端更严格：离开页面后 audio 元素常被浏览器自动 suspend，iOS 还叠加静音开关限制
用 BackgroundAudioManager 替代 InnerAudioContext 做全局管理
微信小程序原生的 getBackgroundAudioManager() 是唯一支持跨页面、后台播放、系统级状态同步的音频 API。它天然适合封装成全局单例，且避开了 obeyMuteSwitch 在 iOS 上的坑（默认就不受静音键影响）。
实操建议：
- 在
App.vue的onLaunch中初始化并挂载到uni.$audio或globalThis.$audio - 统一监听
onPlay、onPause、onTimeUpdate，用uni.$emit广播状态变更 - 所有页面通过
uni.$on('audio:status-change', handler)订阅，而非直接操作实例 - 避免混用
InnerAudioContext和BackgroundAudioManager，二者底层通道不同，无法互相控制
示例初始化：
onLaunch() {
// #ifdef MP-WEIXIN
const bgm = wx.getBackgroundAudioManager()
uni.$audio = bgm
bgm.onPlay(() => uni.$emit('audio:status-change', { playing: true }))
bgm.onPause(() => uni.$emit('audio:status-change', { playing: false }))
// #endif
}
如何让 InnerAudioContext 在 iOS 微信小程序里响起来
如果你必须用 InnerAudioContext（比如需要精确控制播放位置、无系统 UI 干扰），绕过 iOS 静音键的唯一可靠方式是提前调用 wx.setInnerAudioOption({ obeyMuteSwitch: false })。
关键细节：
- 必须在首次创建任何
InnerAudioContext实例之前调用，否则无效 - 仅对后续新建的 context 生效，已存在的实例不受影响
- 只在微信小程序生效（
#ifdef MP-WEIXIN），其他平台忽略 - 该设置是进程级的，应用内所有
InnerAudioContext实例都继承此行为
典型错误写法：onLoad 里先 uni.createInnerAudioContext() 再调 wx.setInnerAudioOption —— 此时已经晚了。
销毁音频实例时最容易被忽略的三件事
内存泄漏和残留播放在真机上极难复现，但一旦发生，用户反馈往往是“退出页面后还在响”或“再进页面声音变小/卡顿”。根本原因不是忘了 destroy()，而是没理清生命周期边界。
- 在
onUnload中调用stop()+destroy()，但若页面被redirectTo跳转，onUnload不触发 → 改用onHide+ 标记页面是否真正离开 -
BackgroundAudioManager没有destroy方法，但需手动清除所有onXxx监听器，否则重复绑定导致事件触发多次 - 使用
uni.createInnerAudioContext()时，若设置了autoplay: true，H5 端可能因未交互而静默失败，此时实例仍存在但处于 pending 状态，需监听onError并主动清理
复杂点在于：iOS 微信里，BackgroundAudioManager 的播放状态和系统锁屏控件强耦合，而 InnerAudioContext 完全无此能力——选哪个，本质是在“可控性”和“系统兼容性”之间做取舍。
