APP启动时检查定位权限而非网络权限，因uni.getConnectedWifi依赖位置授权获取SSID等WiFi详情，而uni.getNetworkType无需权限但仅返回粗粒度类型且不可靠；需分平台用plus.ios/plus.android检测系统开关与应用授权状态，并在plus.ready后执行。
APP启动时检查网络权限，本质是检查「定位权限」——因为uni-app里获取WiFi详情（如SSID）必须依赖位置权限，而网络类型判断（uni.getNetworkType）本身不需权限，但业务上常误以为它需要。
为什么启动时查的不是“网络权限”而是“定位权限”
Android 10+ 和 iOS 13+ 把 WiFi 扫描能力与位置权限强绑定：uni.getConnectedWifi 调用前必须已获得 scope.userLocation 授权，否则直接 fail。而 uni.getNetworkType 虽能返回 "wifi" 或 "cellular"，但它不校验权限、也不提供 SSID，纯属系统网络栈快照——所以你真正要检查的，是定位权限是否就位。
- iOS 上若未声明
NSLocationWhenInUseUsageDescription，云打包会直接失败，报错含"NSLocationWhenInUseUsageDescription is missing" - Android 端若 manifest.json 里没勾选
ACCESS_FINE_LOCATION，uni.authorize({ scope: 'scope.userLocation' })会静默失败，不弹窗也不报错 -
uni.getNetworkType在 App 端返回值不可靠：iOS 常缓存旧值，某些安卓 ROM 返回"unknown"即使有网
启动时分平台检测定位权限的实操路径
不能只调 uni.getSetting，它在未申请过时 iOS 返回 {}、Android 返回 {authSetting:{}}，无法区分「未申请」「拒绝」「永久拒绝」。
- iOS：先用
plus.ios.importClass('CLLocationManager').locationServicesEnabled()查系统定位总开关；再调CLLocationManager.authorizationStatus()，返回3（kCLAuthorizationStatusAuthorizedWhenInUse）才算可用 - Android：先用
plus.android.checkPermission('android.permission.ACCESS_FINE_LOCATION')查原生权限状态；再用plus.android.importClass('LocationManager').isProviderEnabled('gps')查 GPS 是否开启（注意：部分设备用'network'提供器） - 两者都必须在
plus.ready后执行，否则plus.android/plus.ios为 undefined
用户拒绝后怎么引导跳设置页才不白忙活
uni.openSetting() 在 iOS 上只能打开总设置页，且 iOS 15+ 下若用户「完全关闭应用所有权限」，该 API 会静默失败；Android 虽支持 intent 深度跳转，但 uni-app 封装层屏蔽了具体权限页跳转能力，实际仍打开应用设置首页。
- 调用前务必确认是「永久拒绝」：
plus.android.requestPermissions的回调中deniedAlways.length > 0，或 iOS 原生AVCaptureDevice.authorizationStatusForMediaType('vide')返回2 - 文案必须写清用途，例如「需要位置权限以识别当前WiFi网络」，否则苹果审核可能拒审
- 跳转失败时 fallback 到提示复制路径：
“请前往「设置 → 隐私与安全性 → 定位服务 → [你的App]」手动开启”
最易被忽略的是：**系统定位总开关关闭时，即使 App 权限已授，uni.getConnectedWifi 仍会失败，且错误信息无明确提示——必须把系统级和应用级检测拆成两步，缺一不可。**
