uni.startlocationupdatebackground需配合manifest配置和原生权限才能生效，ios须声明uibackgroundmodes为location，android需申请access_background_location并设为“始终允许”，微信小程序不支持，监听器必须在success回调中注册，纯js方案易失效，推荐使用ba-locationamap等原生插件。
uni.startLocationUpdateBackground 必须配合 manifest 和原生权限才生效
直接调用 uni.startLocationUpdateBackground 几乎必然失败——它不是 JS 层面的开关，而是系统级能力的触发器。不提前在配置里声明、不申请对应原生权限，iOS 会静默忽略，Android 则直接报错 permission denied。
- iOS：必须在
manifest.json的app-plus.distribute.ios.UIBackgroundModes中显式写入["location"]，且 Xcode 工程需启用 Background Modes → Location updates - Android：
manifest.json中app-plus.distribute.android.permissions要包含"ACCESS_BACKGROUND_LOCATION"；同时 Android 10+ 设备上，用户必须手动在系统设置中授予「始终允许」位置权限（不能只点「仅在使用时」） - 微信小程序端不支持该 API，仅 App 端可用；若误用于小程序，
uni.onLocationChange永远不会触发，控制台也无提示
uni.onLocationChange 监听器注册顺序不能错
监听器必须在 uni.startLocationUpdateBackground 成功回调之后再注册，否则 iOS 会丢弃首次定位事件，Android 可能收不到任何更新。
- 错误写法：
uni.onLocationChange(() => {}); uni.startLocationUpdateBackground()—— 监听器注册太早，系统尚未建立后台定位通道 - 正确写法：在
startLocationUpdateBackground的success回调里调用uni.onLocationChange - 注意：
uni.onLocationChange是「持续监听」，不是一次性回调，不要在每次位置变化后反复注册，否则内存泄漏
后台定位失效的三大隐藏原因
即使 API 调用成功、权限全开，位置仍可能中断——问题往往出在系统策略或设备厂商定制上。
- Android 厂商限制：华为 EMUI 需关闭「自动启动」和「受保护应用」；小米 MIUI 要关「神隐模式」并加入「自启动白名单」；OPPO/Realme 需关闭「冻结应用」
- 电池优化干扰：Android 6.0+ 默认开启电池优化，必须引导用户进入
Settings → Battery → Battery Optimization手动将你的 App 设为「不受限制」 - iOS 后台保活窗口：App 进入后台后，系统只给约 30 秒活跃时间执行 JS；超过后定位服务由原生层接管，但若未集成原生插件（如
Ba-LocationAMap），iOS 会直接终止整个后台进程
真正稳定上报得靠原生插件，不是纯 JS
纯 uni.startLocationUpdateBackground + uni.onLocationChange 在锁屏 5 分钟后大概率失效，尤其在低端 Android 或 iOS 17+ 上。这不是代码 bug，是系统设计使然。
- 推荐插件：
Ba-LocationAMap（高德）、uni-plugin-location（轻量封装）、Tencent-Lite（腾讯精简版） - 关键差异：这些插件内部使用 Foreground Service（Android）和 CLLocationManager + background task（iOS），能绕过 JS 层被挂起的问题
- 必须注意：iOS 插件需用付费 Apple Developer 账号打包，免费账号无法通过 App Store 审核后台定位能力
最常被忽略的一点：后台定位不是“启动就完事”，而是一套状态闭环——从权限检测、前台/后台状态切换响应、到异常重连与降级策略（比如后台失败时切回前台轮询）。漏掉任意一环，上线后就会在特定机型上集体失联。
