uni.getConnectedWifi 不返回 signalStrength 是因 iOS 13+ 禁止获取 RSSI，uni-app 为双端一致主动屏蔽该字段；Android 需原生插件，iOS 无合规途径；推荐用连接稳定性（如 ping 延迟、请求成功率）间接反映信号质量。
uni.getConnectedWifi 无法返回 signalStrength？这是设计如此
uni-app 官方 API uni.getConnectedWifi 在 Android 和 iOS 上均**不返回信号强度（RSSI）值**，只提供 ssid、bssid、ipAddress 等基础连接信息。这不是你调用错了，也不是插件没装好，而是 uni-app 跨平台层主动屏蔽了该字段——因为 iOS 自 iOS 13 起彻底禁止 App 通过公有 API 获取 WiFi 信号强度，而 uni-app 为保持双端一致性，干脆不在返回结构中暴露该字段。
常见错误现象：
• 调用 uni.getConnectedWifi 后打印结果，发现没有 signalStrength 或 rssi 字段
• 查阅文档或社区示例，看到别人“能拿到”，实则是用了原生插件或 iOS 私有 API（已失效或被拒审）
- Android 端若需 RSSI，必须走原生能力（如调用
WifiManager.getConnectionInfo().getRssi()），再通过 uni-app 原生插件桥接 - iOS 端无合规公开途径获取实时 RSSI；
CNCopyCurrentNetworkInfo在 iOS 13+ 已废弃，且需开启「Access WiFi Information」entitlement（仅限企业/教育证书，App Store 不允许） - 不要尝试用
uni.getNetworkType或uni.onNetworkStatusChange拆解信号质量——它们连是否连上 WiFi 都不保证返回准确 ssid，更别说强度
想显示 WiFi 强度？你真正需要的是「周边热点扫描 + RSSI 解析」
准确显示信号强度的唯一可行路径，是主动扫描周围 WiFi 列表，并读取每个热点的 level（Android）或等效 RSSI 值（iOS 有限支持）。这完全超出 uni-app 标准 API 范围，必须依赖原生插件。
使用场景：
• 公司内网覆盖热力图工具
• 智能家居设备配网时辅助选点
• 网络诊断类小程序
- 推荐插件：
Fvv-UniWifiHelper（CSDN 实测可用，Android 支持scanWifiList返回含level的数组；iOS 仅返回空数组或固定 -1，属系统限制） - 调用前必须确保已获得
ACCESS_FINE_LOCATION权限（Android 10+ 强制）和用户位置授权（scope.userLocation） - 注意：扫描是耗电操作，真机测试务必在前台执行，后台触发会被系统静默丢弃
替代方案：用「连接稳定性」间接反映信号质量
当无法获取真实 RSSI 时，更务实的做法是监控连接行为本身——它比数字更能说明问题。
可落地的指标包括：
• 连续 ping 局域网网关（如 192.168.1.1）的丢包率与延迟
• uni.request 向内网服务发轻量 HEAD 请求的成功率与时长
• 检查 uni.getConnectedWifi 调用是否频繁失败（高失败率 ≈ 信号差或权限异常）
- 避免轮询：用
uni.onNetworkStatusChange监听网络切换，仅在网络刚连上 WiFi 时触发一次探测 - 降级友好：若探测失败，直接显示「信号可能较弱」而非报错，不阻断主流程
- 注意 iOS 限制：本地局域网请求需在
manifest.json中配置"usingComponents": true和"mp-weixin"下的networkTimeout，否则超时极快
为什么你的「WiFi 强度」需求大概率被高估了
绝大多数业务场景并不真正需要精确到 dBm 的 RSSI 值。用户感知的「信号好坏」，本质是「能否稳定传数据」。强行追求信号数值，反而会陷入权限弹窗反复失败、iOS 兼容性崩塌、插件维护成本飙升的泥潭。
容易被忽略的地方：
• 用户根本不会看「-67dBm」这种数字，但会立刻注意到「视频卡顿」「打卡失败」「设备控制无响应」
• 同一 RSSI 值在不同路由器、不同信道、不同干扰环境下，实际体验差异巨大
• 真正影响体验的是 TCP 重传率、DNS 解析延迟、DHCP 获取时间等链路层指标，RSSI 只是其中一环
与其花三天调试原生插件拿一个不准的数字，不如用两小时加一个「当前网络状态提示栏」，实时显示「WiFi 已连接｜传输中｜响应慢｜已断开」——用户要的从来不是数字，是确定性。
