app端必须用uni.getbackgroundaudiomanager()实现锁屏播放，它直接桥接ios avaudiosession和android mediasession；manifest需手动配置uibackgroundmodes和permissions；播放前须填title、singer、coverimgurl；播放须用户手势触发；状态监听依赖manager事件而非页面生命周期；h5端需条件编译隔离。
uni-app App端必须用 uni.getBackgroundAudioManager()，不是可选而是强制
App 端实现锁屏后持续播放、支持系统控制条（如锁屏界面播放/暂停按钮），uni.getBackgroundAudioManager() 是唯一合规且稳定的入口。它不是“增强版 audio”，而是直接桥接 iOS 的 AVAudioSession 和 Android 的 MediaSession，让系统知道“这个 App 正在播音乐”，从而授予后台运行资格。用 uni.createInnerAudioContext() 或 <audio></audio> 标签，在真机锁屏后基本 1–3 秒内就会被静音或中断，尤其 iOS 上几乎必然失效。
manifest.json 权限配置必须精确到字段层级，漏一项就白忙
改 manifest 不是勾个选项就行，必须手动编辑源码视图，且 iOS 和 Android 配置不能混写：
- iOS 配置要嵌套在
"app-plus" → "distribute" → "ios"下，写成："UIBackgroundModes": ["audio"]（注意是数组，不是字符串，“audio”不能拼错、不能带空格） - Android 配置在
"app-plus" → "distribute" → "android"下，"permissions"必须是字符串数组，正确写法：["<uses-permission android:name='\"android.permission.WAKE_LOCK\"'></uses-permission>"]（XML 标签必须转义，结尾斜杠不能少） - 改完后必须重新云打包——本地调试、热更新、HBuilderX 模拟器均不生效；打包日志里应出现类似
background audio enabled的提示才表示成功
播放前必须填全三项元数据，iOS 锁屏界面才显示控制条
iOS 锁屏界面只认 title、singer、coverImgUrl 这三个字段，缺任意一个，系统就当“无媒体信息”，直接不渲染控制条。Android 虽然容忍度稍高，但这也是基础门槛：
-
coverImgUrl必须是 HTTPS 地址，且尺寸建议 ≥ 300×300，否则通知栏缩略图模糊或空白 -
src推荐用远程 HTTPS 地址；App 端若用本地路径（如/static/bgm.mp3），需确认打包后路径解析正确，否则静音无报错 - 播放动作必须由用户手势触发（比如按钮点击回调），不能在
onLoad或onShow里自动调play()，否则 iOS/Safari 微信会拦截且不抛错
监听状态变化别依赖页面生命周期，要用 manager 自身事件
onHide 和 onShow 与音频实际状态不同步：用户从锁屏点播放键时，页面根本没 onShow，但 manager.onPlay 一定会触发。可靠监听方式只有：
manager.onPlay(() => { /* 实际开始播放 */ })manager.onPause(() => { /* 用户主动暂停 */ })manager.onEnded(() => { /* 播放结束，需手动 seek(0) + play() 实现循环 */ })- 不要设
manager.loop = true—— 它在后台无效，且 iOS 有 100–300ms 间隙，必须手动重播
最易被忽略的是：H5 端 uni.getBackgroundAudioManager() 会静默降级，既不报错也不起作用，必须用条件编译隔离处理，否则真机测试时会误判为代码问题。
