微信小程序中uni.getBackgroundAudioManager()必须在用户点击等交互后首次调用并play()，不能在onLoad/onShow自动触发，否则iOS拒绝音频焦点导致锁屏无法唤醒；需至少填写title、singer、epname两项，coverImgUrl须HTTPS且≥300×300，赋值src后必须显式调用play()。
uni.getBackgroundAudioManager() 初始化时机不对
锁屏后无法唤醒，第一反应不是配置问题，而是 manager 实例没在正确时机初始化。微信小程序里，uni.getBackgroundAudioManager() 必须在用户主动交互（如按钮点击）后首次调用，不能在 onLoad 或 onShow 里自动触发播放——iOS 会直接拒绝音频焦点请求，连错误都不抛。
常见错误：页面一进来就 manager.src = 'xxx.mp3'; manager.play();，结果锁屏后点通知栏无响应。这是因为系统判定“非用户手势启动”，直接静音处理。
- 必须用 button 点击、touchstart 等明确交互事件触发首次
play() - 首次播放前，
title、singer、epname至少填两个，否则 iOS 锁屏界面不显示控制条，用户根本点不到 - 不要在
onHide里调manager.pause()再等onShow恢复——切后台时 manager 仍存活，但状态可能已脱钩；应监听manager.onPlay和manager.onPause做状态同步
manifest.json 权限配置漏项或位置错
App 端锁屏失效，90% 是 manifest.json 写错了位置或格式。这个配置不是“勾一下就行”，它必须精确嵌套，且不同平台不能混写。
iOS 要求 app-plus.distribute.ios.UIBackgroundModes 是数组 ["audio"]，拼成 "audio" 字符串或写成 ["playback"] 都无效；Android 则需在 app-plus.background.mode 设为 "audio"，同时确保 app-plus.modules.Audio 为 {} 启用模块。
- 改完 manifest 后必须重新云打包，热更新和本地调试不生效
- 真机测试前，检查打包日志是否出现
background audio enabled类提示 - Android 还要确认
permissions包含<uses-permission android:name="android.permission.WAKE_LOCK" />（注意 XML 标签转义）
src 地址协议或路径不合法
锁屏后无声，但前台播放正常？大概率是 src 地址不满足后台要求。iOS 强制 HTTPS，Android 部分机型也拒绝 HTTP；App 端不支持 file:// 协议或相对路径，/static/xxx.mp3 在真机后台大概率静音。
- App 端必须用 HTTPS URL，例如
https://cdn.example.com/book.mp3 - 小程序端可接受
/static/xxx.mp3，但必须放在/static/目录下，不能用@/static/或~static/ - coverImgUrl 必须是 HTTPS，尺寸 ≥ 300×300，否则 Android 微信通知栏缩略图模糊或不显示
- 赋值
src后必须显式调用manager.play()，光设 src 不会加载也不播放
跨平台误用 API 导致逻辑断裂
在支付宝、字节、快应用里硬套微信方案，是锁屏唤醒失败最隐蔽的原因。这些平台压根没提供 BackgroundAudioManager 等效接口，uni.getBackgroundAudioManager() 在它们内部返回空对象或直接报错。
别在非微信平台写 if (uni.getBackgroundAudioManager()) {...} 就以为能 fallback——实际运行时 manager 为 undefined，后续所有操作都静默失败。
- 务必用条件编译隔离：仅在
#ifdef MP-WEIXIN下使用uni.getBackgroundAudioManager() - H5 端该 API 完全无效，降级用
new Audio()+document.visibilityState监听 - App 端不要混用
uni.createInnerAudioContext()和uni.getBackgroundAudioManager()，后者会抢占音频焦点，前者在后台必然中断
