uni.getLocation调用后卡住是因默认无超时，弱信号下系统级定位服务挂起；应显式设timeout为8000ms，并分层降级：IP定位→缓存坐标→手动选择城市。
uni.getLocation 调用后卡住、无响应、不进 success 也不进 fail
这不是网络慢，而是定位策略在弱信号下陷入等待——uni.getLocation 默认不设超时，系统级定位服务（尤其 Android）在 GPS 未冷启动或室内无卫星时，可能挂起十几秒甚至更久，UI 卡死，用户误以为崩溃。
实操建议：
-
timeout参数必须显式设置，推荐8000（8 秒），不能依赖默认值（文档未定义，默认行为由各端原生实现决定，iOS 可能更激进，Android 更“执着”） - 不要只靠
fail回调判断失败：部分 Android 机型（如 OPPO、vivo）在权限未授予或定位服务关闭时，fail不触发，success也不来，直接静默；需配合uni.getSetting提前校验 - 真机测试务必关掉模拟位置开关，开发者选项里的「模拟位置应用」若设为其他 App，会导致
uni.getLocation返回错误坐标或无限等待
超时后怎么兜底？别只 retry 一次
单纯重试 uni.getLocation 很容易陷入“超时 → retry → 再超时”的死循环，尤其在电梯、地下车库等场景。真正可用的兜底是分层降级。
实操建议：
- 第一层：8 秒超时后，立即 fallback 到 IP 定位（调用后端接口，传
uni.getSystemInfoSync().platform和网络类型，后端用高德 IP 定位 API） - 第二层：IP 定位失败或精度 > 5000 米时，返回上一次缓存的有效坐标（需本地
uni.setStorageSync存储，带时间戳，超过 10 分钟则丢弃） - 第三层：全部失效时，显示「定位不可用，请手动选择城市」入口，跳转
uni.chooseLocation（仅 App 和小程序支持）
Android 12+ 和 iOS 的超时表现差异很大
同一段代码，在不同平台超时逻辑完全不同：Android 系统可能返回 errCode: -1（权限拒绝）或 errCode: 3300（定位服务未开启），而 iOS 更倾向静默失败或抛 getLocation:fail system error，且不带具体码。
实操建议：
- iOS 真机必须确保
manifest.json中app-plus.distribute.ios.plist.NSLocationWhenInUseUsageDescription非空，否则连弹窗都不出现，自然没回调 - Android 12+（API 31）需在
manifest.json的app-plus.distribute.android.permissions显式声明android.permission.ACCESS_FINE_LOCATION和android.permission.ACCESS_COARSE_LOCATION，否则系统直接拦截，fail里errMsg可能为空字符串 - 不要用
uni.authorize({ scope: 'scope.userLocation' })做前置检查——它在 Android 上基本无效，在 iOS 上无法触发弹窗；改用uni.getSetting查authSetting['scope.userLocation']
为什么加了 timeout 还是卡住？检查 isHighAccuracy
isHighAccuracy: true 会强制走 GPS 模块，在无天空视野时极易超时；但设为 false 又可能退化为基站定位（误差几公里）。这不是二选一，而是要动态切换。
实操建议：
- 首次定位用
isHighAccuracy: true+timeout: 8000，追求精度 - 超时后第二次尝试改用
isHighAccuracy: false+timeout: 3000，快速拿个粗略坐标保流程不中断 - 注意：部分华为/小米机型即使
isHighAccuracy: true，也因系统限制无法启用 GPS，type: 'gcj02'才是坐标系可控的唯一变量，别指望isHighAccuracy能解决所有偏移问题
超时不是孤立问题，它总和权限状态、坐标系选择、设备型号、系统版本缠在一起。最常被忽略的是：你看到的“没反应”，90% 是因为 manifest 配置漏项导致原生层根本没启动定位服务，而不是 JS 层卡住了。
