uni-app无法直接打开系统设置开关，只能跳转设置页，且iOS与Android行为不同：需先调uni.getAuthSetting检查权限状态，undefined时调uni.authorize，false时才可调uni.openSetting；Android直达权限页，iOS仅到App主设置页，须引导用户手动操作；onShow中需重检权限并延时获取最新值。
uni-app 无法直接“打开系统设置开关”，只能跳转到对应设置页，且 iOS 和 Android 行为完全不同——不加判断就调 uni.openSetting，大概率静默失败或闪退。
uni.openSetting 调用前必须确认权限已被明确拒绝
用户首次点击定位按钮时，uni.getAuthSetting 返回的 scope.userLocation 是 undefined（未询问），不是 false（已拒绝）。此时直接调 uni.openSetting，iOS 无反应，Android 可能报错或闪退。
- 先调
uni.getAuthSetting，检查目标 scope 字段值 - 只有值为
false时，才可安全调uni.openSetting - 若为
undefined，应先调uni.authorize({scope: 'scope.userLocation'})弹原生授权框 - 若为
true，权限已开，无需跳转
Android 跳转到具体权限页，iOS 只能跳 App 主设置页
这是系统级限制，不是 uni-app 能绕过的。你在 Android 上调 uni.openSetting() 会直达「设置 > 应用 > [你的App] > 权限」；而在 iOS 上，它只打开「设置 > [你的App]」主页面，不会进入「隐私与安全性 > 定位服务」等子页。
- iOS 必须在 UI 上同步提示：“请手动点击「隐私与安全性」→「定位服务」开启”
- 不要尝试用
plus.runtime.openURL('app-settings:')或App-Prefs:root=...替代 —— iOS 16+ 已基本拦截，且无回调、无法兜底 - Android 也不建议硬编码 Intent Action（如
android.settings.BLUETOOTH_SETTINGS），因版本兼容性差；uni.openSetting是唯一跨版本稳定的入口
onShow 中必须重检权限并更新 UI
用户从设置页返回后，uni.getAuthSetting 结果可能已变，但 Vue 组件不会自动刷新。只在按钮点击时检查一次，UI 就会滞后。
- 在
onShow生命周期里再次调uni.getAuthSetting - 根据结果动态更新按钮文案（如「去设置」→「已授权」）
- 禁用/启用功能入口（如隐藏「使用定位」开关，改为显示当前位置）
- 避免用户以为“刚开了权限，App 却没反应”
原生插件不是必需，也别轻易上
想通过原生插件实现更细粒度跳转（比如直达蓝牙、Wi-Fi 设置），看似可行，但实际成本远高于收益：
- 需要同时维护 Android
.aar和 iOS.framework，且package.json、目录名、调用名三处必须完全一致，错一位就undefined - iOS 系统限制严格，绝大多数二级设置页（通知、蓝牙、飞行模式）根本无法通过 URL Scheme 直达
- HBuilderX 3.9+ 对
plus.runtime.openURL的支持持续收紧，插件方案反而更容易失效 - 除非业务强依赖某项不可替代的原生能力，否则坚持用
uni.openSetting+ 清晰引导，是最稳路径
最易被忽略的一点：iOS 上用户从设置页返回后，onShow 里调 uni.getAuthSetting 得到的仍是旧缓存值——必须加 setTimeout(() => {...}, 300) 或监听 plus.webview.currentWebview.onPageResume 才能拿到最新状态。这个延迟不是 bug，是系统 WebView 生命周期的真实表现。
