app端调用原生音频播放器必须用plus.audio.createplayer()，因其直接对接ios avplayer和android mediaplayer；uni.createinneraudiocontext()和uni.getbackgroundaudiomanager()均属js层封装，在app端不生效，无法实现锁屏控制、后台持久化及系统通知栏进度条。
App端调用原生音频播放器，不能靠 uni.createInnerAudioContext() 或 uni.getBackgroundAudioManager() —— 它们走的是 JS 层封装，不是真正“原生播放器”。要调用系统级播放器（比如 iOS 的 AVPlayer、Android 的 MediaPlayer），必须用 plus.audio 系列 API，且仅在 App 环境生效。
为什么必须用 plus.audio 而不是 uni.xxx
uni.createInnerAudioContext() 是 Webview 内的音频上下文，受 WebView 渲染线程限制；uni.getBackgroundAudioManager() 本质是微信小程序兼容层，在 uni-app App 端不生效（它只对微信小程序环境有定义）。真正在 App 中调起原生播放器、支持锁屏控制、后台持久化、系统通知栏进度条的，只有 plus.audio 提供的接口。
- App 启动后需等待
plus.ready触发，否则plus.audio对象未初始化，调用直接报错或返回undefined - 仅限 App 平台：必须用
uni.getSystemInfoSync().platform === 'app'包裹，避免 H5 或小程序里执行时报错 - 不支持自动播放：首次播放仍需用户手势触发（如按钮点击），否则 iOS 会静默拒绝
plus.audio.createPlayer() 初始化要点
这是最接近“原生播放器”的接口，比 plus.audio.play() 更可控，支持暂停、seek、监听状态变化、绑定锁屏控件。
-
src必须是 HTTPS 远程地址或本地file://路径（如file:///data/user/0/xxx/files/audio.mp3），/static/相对路径在打包后无法被原生层解析 - 需手动调用
player.start()启动，不能设autoplay: true—— 该参数在createPlayer()中无效 - 必须监听
player.onstatechange，状态码4表示播放中，2表示就绪，0表示空闲；不监听就无法知道是否真播起来了 - iOS 上若没填
title和cover，锁屏界面不显示控件，但音频仍在播；Android 则可能连通知栏都不出现
后台播放失败的三个硬性条件检查项
即使代码写对，90% 的“切后台就停”问题都卡在这三处，缺一不可：
- manifest.json 的
app-plus节点下，必须有"backgroundMode": ["audio"]（不是requiredBackgroundModes，那是微信小程序字段） - Android 需额外在
android.permission.FOREGROUND_SERVICE权限勾选启用（HBuilderX 项目设置 → 模块配置 → 原生插件 → Audio） - iOS 需在 Xcode 工程中手动开启 “Background Modes → Audio, AirPlay, and Picture in Picture”，否则系统直接终止进程
常见错误现象与对应修复
遇到无声、卡住、状态不更新，先看这些：
- 调用
plus.audio.createPlayer()后player是null→ 没等plus.ready，或平台判断漏了platform === 'app' - 播放时控制台报
errCode: 1001→ 多数是音频源跨域或非 HTTPS，iOS 强制拦截，Android 部分机型也拒绝 - 锁屏无控件、通知栏无进度 → 缺
title/cover/duration元数据，或 iOS 未开启 Background Modes - 切后台几秒后中断 → manifest.json 的
backgroundMode配置位置错（必须在app-plus下，不是根节点或mp-weixin下）
原生播放器的复杂点不在 API 调用本身，而在平台权限、路径协议、生命周期时机三者的咬合——漏掉任意一个，表现都是“没声音”，且往往没报错。
