uni.getwifilist 在 app 端无法获取真实 wifi 列表：ios 因系统限制始终为空或报错，android 需原生插件调用 scanwifi() 并处理零宽字符；替代方案是监控连接稳定性（如 ping 丢包率、http 成功率）来间接评估网络质量。
uni.getWifiList 在 App 端根本拿不到真实列表
直接说结论：uni.getWifiList 在 uni-app 编译的原生 App（app-plus）中默认不返回有效 WiFi 列表，iOS 上基本为空或报错，Android 上即使权限全开也常返回空数组。这不是你代码写错了，而是官方 API 未封装完整扫描逻辑——它不触发 WifiManager.startScan()，也不监听系统广播，只查缓存（通常为空）。
常见错误现象：uni.getWifiList 成功回调但 wifiList 是空数组；控制台无报错但真机上始终扫不到任何热点；iOS 上直接进 fail 回调，错误码可能是 10005 或提示 “not authorized”。
必须满足的硬性前提：
-
uni.startWifi()必须先调用，否则后续全部失败 - Android 需动态申请
scope.userLocation，仅 manifest 声明ACCESS_FINE_LOCATION不够 - iOS 需开启设备「定位服务」且 Info.plist 含
NSLocationWhenInUseUsageDescription，但即便如此，iOS 13+ 仍禁止返回真实扫描结果
Android 端可用但必须走原生插件路径
要真正拿到含信号强度（RSSI / level）的 WiFi 列表，Android 必须依赖原生能力封装。官方 SDK 不提供 scanWifiList 这类方法，JS 层无法绕过系统限制直接读取扫描结果。
实操建议：
- 使用经实测的插件如
Fvv-UniWifiHelper（CSDN 可搜到），它封装了startScan+ 广播监听 + 权限适配，暴露scanWifi()方法 - 调用前确保 WiFi 已开启：
uni.setWifiEnabled({ enable: true }) - 扫描结果中的
level字段即 RSSI（单位 dBm），值越接近 0 表示信号越强（如-48比-72强） - 注意清洗 SSID：部分 Android 设备返回的
SSID含零宽字符（如\u200e），建议用.trim().replace(/[\u200e\u200f\u202a-\u202e]/g, '')处理
iOS 端没有合规的实时 RSSI 获取方式
iOS 自 iOS 13 起彻底移除了公有 API 对 WiFi 扫描和 RSSI 的访问能力。CNCopyCurrentNetworkInfo 已废弃，NEHotspotNetwork 仅支持已连接网络的 BSSID/SSID，不提供信号强度。Apple 明确要求：App 只能连接已知网络，不得主动探测周边热点。
这意味着：
-
Fvv-UniWifiHelper等插件在 iOS 上返回空数组或固定-1，属系统级限制，非插件缺陷 - 试图通过私有 API 或越狱方案获取 RSSI，会导致 App Store 审核被拒
- 跳转系统设置页（
uni.openSystemSetting()）是唯一合规提示用户手动操作的方式
别浪费时间尝试 JS 层 hack —— iOS 的 WiFi 扫描能力对第三方 App 是关闭的，不是“还没适配好”，而是“不允许你打开”。
替代方案：用连接稳定性代替信号数字
当无法获取真实 RSSI 时，更务实的做法是监控连接行为本身。一个频繁丢包、高延迟的 WiFi，再好看的 -45dBm 数字也没意义。
可落地的间接指标：
- 向局域网网关（如
192.168.1.1）发起连续ping，统计丢包率与平均延迟 - 向同一内网服务地址发起 HTTP 请求（如
/health），记录成功率与 P95 响应时间 - 结合
uni.getConnectedWifi()获取当前 SSID，再比对历史连接成功率做趋势判断
这个思路不依赖系统扫描权限，双端一致，且更贴近用户真实体验。信号强度数字容易误导，而“连不上”“卡顿”“超时”才是用户真正感知到的问题。
复杂点在于：扫描列表 + RSSI 是硬件级能力，跨平台一致性天然残缺；而连接稳定性指标虽弱于原始数据，却是目前唯一能在 iOS 和 Android 上同时落地、不踩审核红线的方案。
