最常见原因是 uni.getbackgroundaudiomanager() 实例未填全 title、singer、coverimgurl 三个字段，ios 缺一即隐藏锁屏控件；manifest.json 中 uibackgroundmodes 配置错误或未云打包也会导致失效。
uni.getBackgroundAudioManager() 的 title/singer/coverImgUrl 缺失
锁屏界面不显示音频信息，最常见原因是 uni.getBackgroundAudioManager() 实例没填全三个关键字段：title、singer、coverImgUrl。iOS 系统极其严格：缺任意一个，就直接隐藏整个锁屏控件，连“未知歌曲”都不显示。
实操建议：
-
title必须设，且不能为空字符串或纯空格 -
singer推荐设，iOS 锁屏界面会优先展示它；不设时部分机型可能 fallback 到epname，但不可靠 -
coverImgUrl必须是 HTTPS 地址，尺寸 ≥ 300×300 像素；Android 微信通知栏对尺寸更敏感，小图会被模糊或裁切 - 赋值顺序无关紧要，但必须在调用
play()前完成设置
iOS manifest.json 配置错位或拼写错误
即使 JS 层字段全了，iOS 真机仍不显示锁屏控件，大概率是 manifest.json 里 UIBackgroundModes 没生效。这个配置不是“勾个选项”就行，而是必须精确嵌套在 app-plus → distribute → ios 下，且格式容错极低。
常见错误现象：
- 写了
"UIBackgroundModes": "audio"（字符串）→ 应为数组：["audio"] - 写成
["playback"]或["audio", "location"]→ iOS 只认["audio"]单项 - 把配置放在
mp-weixin或顶层h5节点下 → 完全无效 - 改完没重新云打包 → 本地调试和热更新无法触发原生权限注册
Android 锁屏控件未启用 MediaSession 或缺少 WAKE_LOCK
Android 行为比 iOS 更隐蔽：它可能“播得动”，但锁屏界面空白或只显示播放按钮、无封面/标题。这是因为系统 MediaSession 没被正确激活，或后台保活失败导致音频服务被杀。
实操建议：
- 确保
manifest.json中app-plus.background.mode设为"audio"（注意是字符串，不是数组） - Android 权限必须显式声明：
"permissions": ["<uses-permission android:name='\"android.permission.WAKE_LOCK\"'></uses-permission>"]，XML 标签要转义、斜杠不能省 - 别依赖
uni.createInnerAudioContext()+plus.audio.setLockScreenControl()组合——该 API 仅在原生渲染模式下有效，且需包裹#ifdef APP-PLUS - 真机测试时优先选华为、小米等国产机型，它们对
WAKE_LOCK更敏感，问题暴露更快
微信小程序平台误用了 uni.createInnerAudioContext()
在微信小程序里调用 uni.createInnerAudioContext() 后锁屏无信息，不是配置问题，而是根本走错了 API 路径。这个 API 在小程序中就是 InnerAudioContext 封装，生命周期绑定页面，一进后台 JS 上下文就停，监听器全失效，系统根本不给锁屏控制权。
必须用 uni.getBackgroundAudioManager()，且注意：
- 它只在微信平台存在，其他小程序平台（支付宝、字节）返回
undefined，不能硬调 - 不能在
onLoad里每次新建实例并重复绑定onPlay—— 容易事件触发多次、状态错乱 - 推荐全局单例：在
App.vue的onLaunch中初始化并挂到uni.$bgm，后续所有页面复用 - 调用
play()前，确保用户已触发过交互（如点击播放按钮），否则 iOS 微信会静音拦截
真正卡住人的地方往往不在代码逻辑，而在 manifest.json 的 JSON 结构嵌套层级、字段大小写、数组/字符串类型，以及云打包是否真的生效——这些细节改错一个，锁屏信息就彻底消失，还不会报错。
