静默定位在uni-app app端无法真正实现，因ios和android均强制要求后台定位须经用户明确授权scope.userlocationbackground并声明对应权限，且javascript定时器在后台会被系统挂起，必须使用plus.geolocation.watchposition配合uni.startlocationupdatebackground等原生能力。
静默定位在uni-app App端无法真正实现——系统不允许无感知、无用户授权、无前台交互的持续定位。所谓“静默”，常被误解为“不弹窗、不提示、自动运行”，但iOS和Android均强制要求：后台定位必须经用户明确授权（scope.userLocationBackground），且首次申请时必须有清晰用途说明；任何绕过权限弹窗或伪造用户同意的行为，都会导致审核拒审（iOS）或运行时被系统静默终止（Android厂商ROM）。
为什么 uni.getLocation + setInterval 在后台会失效
这是最典型的误用。App退到后台后，JavaScript线程会被系统挂起（尤其Android省电策略激进的机型，如小米、华为、OPPO），setInterval 停摆，uni.getLocation 根本不会执行。
- Android：从Android 8.0起，后台服务受限；Android 10+ 强制要求
ACCESS_BACKGROUND_LOCATION权限，且仅声明不够，必须动态申请并获用户“始终允许” - iOS：未配置
UIBackgroundModes: ["location"]或未获取scope.userLocationBackground，App进入后台2秒内定位即中断 - 所有平台：单纯依赖JS定时器 ≠ 后台保活，它没有唤醒能力，也不触发系统定位服务保活机制
必须用 plus.geolocation.watchPosition + 后台更新能力
App端真正的后台持续定位，只能走 plus.geolocation.watchPosition 配合 uni.startLocationUpdateBackground（uni-app 3.99+ 推荐）或原生插件方案。核心不是“怎么调API”，而是“怎么让系统认可你的后台定位合法性”。
- 先确保 manifest.json 已声明：
ACCESS_BACKGROUND_LOCATION（Android）、UIBackgroundModes: ["location"]（iOS） - 运行时必须调用
uni.authorize({scope: 'scope.userLocationBackground'})，且用户点击“始终允许”——不能跳过，不能默认勾选 - 调用
uni.startLocationUpdateBackground()后，系统会启用原生后台定位服务，此时plus.geolocation.watchPosition才能持续回调（注意：不是uni.getLocation） - 回调中拿到位置后，建议立即上传或存入本地缓存（如
uni.setStorageSync），避免因网络延迟错过时机
常见错误现象与对应解法
定位突然中断、息屏后停止、后台上报断连——90%源于以下三类问题：
-
权限链断裂：只申请了
scope.userLocation（前台），没申请scope.userLocationBackground；或Android申请了但没在 manifest.json 中声明ACCESS_BACKGROUND_LOCATION—— 表现为iOS可运行、Android后台秒停 -
厂商定制限制：小米/华为/OPPO等需手动关闭“电池优化”和“自启动管理”。不能只靠代码，必须在App内引导用户跳转设置页：
plus.android.requestPermissions(['android.permission.ACCESS_BACKGROUND_LOCATION'], ...)后，再调用plus.android.importClass('android.provider.Settings').ACTION_APPLICATION_DETAILS_SETTINGS -
坐标系与 provider 不匹配：设
provider: 'amap'却没在 manifest.json 配高德appkey；或返回wgs84坐标却直接喂给高德地图组件——结果是位置偏移甚至白屏。国内场景一律用type: 'gcj02'
真正难的不是写几行代码，而是把权限申请流程嵌入用户动线、把厂商适配做成可配置的引导模块、把后台定位失败降级为前台重试+本地缓存补偿——这些细节没处理好，功能上线第一天就会被骑手/司机集体反馈“轨迹断了”。
