uni-app实现锁屏音频控制必须使用uni.getbackgroundaudiomanager()，因uni.createinneraudiocontext()仅适用于短效音效且无法支持后台播放；需严格配置title、src、coverimgurl等元数据，ios须在manifest.json中声明audio后台模式并真机测试，h5端需降级为new audio()。
uni-app 调用系统锁屏音频控制器，核心就是走 uni.getBackgroundAudioManager() 这条通路——它不是“调用控制器”，而是让系统自动为你挂载控制器。iOS 锁屏界面、Android 通知栏、微信小程序控制中心的播放控件，全靠它触发，没别的入口。
为什么 uni.createInnerAudioContext() 完全无效
这个 API 创建的是页面级音频实例，生命周期绑定在当前 Vue 组件上。一旦切后台、锁屏或切换 Tab，JS 执行环境被系统暂停，所有事件监听器（onTimeUpdate、onEnded）立即失效，实例可能被直接销毁。iOS 尤其严格，连静音都不提示，直接无声。这不是兼容性问题，是平台设计使然。
-
uni.createInnerAudioContext()只适合按钮音效、表单反馈等毫秒级短音频 - 它不注册系统音频会话，系统根本不知道你在播什么，自然不会渲染锁屏控件
- 哪怕你手动调用
play()，锁屏后几秒内必停，且无法通过onHide或定时器恢复
uni.getBackgroundAudioManager() 的初始化硬性条件
这个 API 返回的对象本身不报错，但缺任意一项配置，锁屏控件就出不来——尤其 iOS，连“未知歌曲”都不会显示。
-
title和src必填；coverImgUrl强烈建议填（iOS 锁屏封面尺寸需 ≥ 300×300，HTTPS 协议） -
src必须是可直连的 HTTPS 地址；/static/xxx.mp3在 App 端真机锁屏时大概率静音（file:// 协议不被后台音频会话信任） - 首次
play()必须由用户手势触发（如button @click），不能在onLoad或onShow自动调用，否则 iOS 直接拒绝 - H5 端该 API 无后台能力，调用后静默失败，需用
uni.getSystemInfoSync().platform === 'h5'主动降级为new Audio()
App 端必须配 manifest.json 的原生权限
JS 层再正确也没用，原生层没“报备”，系统根本不给你后台音频资格。
- iOS：在
manifest.json的app-plus.distribute.ios.UIBackgroundModes中填["audio"]（注意不是["playback"]或空数组） - Android：在
app-plus.background.mode设为"audio"，同时确保app-plus.modules.Audio为{} - 配置完必须重新云打包——本地调试器不生效，真机测试才看得出锁屏控件是否出现
- 支付宝、快应用等平台压根没提供后台音频接口，
uni.getBackgroundAudioManager()在这些端返回空对象或报错，不可硬套
微信小程序端的特殊限制
微信的 uni.getBackgroundAudioManager() 是独立实现，和 App 端互不兼容，但它有自己的一套规则：
- 必须在用户点击后调用
play()，不能自动播 -
title、singer、epname至少填两个，否则 iOS 锁屏只显示“未知” -
coverImgUrl必须 HTTPS，且建议尺寸 ≥ 300×300，否则 Android 微信通知栏缩略图糊成马赛克 - 赋值
src后必须显式调用play()，光设地址不触发加载 - 切到后台后，不能再用 JS 控制播放/暂停——所有操作必须通过锁屏控件或耳机物理键完成
最容易被忽略的点：锁屏控件不是“调出来”的，是系统根据音频会话状态自动渲染的。你唯一能做的，就是确保 uni.getBackgroundAudioManager() 的元数据、权限、触发时机全部合规，剩下的交给系统。任何试图用 plus.audio.setLockScreenControl() 或模拟按键去“强行激活”的做法，在 iOS 上基本无效，还可能引发审核风险。
