uni.onnetworkstatuschange仅监听网络类型切换（如wifi→5g）和连通性变化（isconnected:true↔false），无法获取带宽、rssi、频段等底层指标；需通过轻量http请求实测吞吐率并结合前台状态兜底判断。
uni-app 无法直接监听“精确网络带宽”切换（如从 50Mbps → 5Mbps），它根本不提供带宽数值、信号强度、吞吐量或实时速率类 API。
uni.onNetworkStatusChange 能监听什么？不能监听什么？
它只响应系统级网络栈的「类型切换」和「连通性变化」，比如：wifi → 5g、isConnected: true → isConnected: false。但不会告诉你当前 WiFi 实际跑的是 200Mbps 还是 2Mbps，也不会暴露 RSSI、SNR、频段（2.4G/5G）、MIMO 状态等底层指标。
常见误判场景包括：
- 连上一个空闲 WiFi（理论带宽 300Mbps），但路由器被限速到 1Mbps ——
uni.onNetworkStatusChange仍返回networkType: 'wifi'，且isConnected: true - 5G 信号弱时自动回落到 4G，但用户实际感知延迟更高、下载更慢 ——
uni.onNetworkStatusChange只触发一次类型变更，不反映带宽劣化过程 - 同一 WiFi 下，多人抢带宽导致可用速率骤降 —— 完全无回调，因为系统网络栈没切换
想间接感知带宽变化，只能靠业务层主动探测
真正能反映“当前可用带宽”的，是你自己的请求表现。必须绕过 uni.getNetworkType 和 uni.onNetworkStatusChange 的抽象层，用轻量 HTTP 请求实测：
- 选一个稳定、低负载的接口（例如
/ping或/health），响应体控制在 1KB 以内 - 记录请求耗时（
startTime到end）和响应大小，计算粗略吞吐率：size / duration（单位 KB/s） - 连续 3 次请求平均速率 50%，可判定为“带宽受限”，而非单纯断网
- 避免高频探测：建议每 30 秒最多测 1 次，否则影响用户体验和服务器压力
注意：别用 uni.uploadFile 测速 —— 它受文件大小、分片、服务端限速干扰太大；也别依赖 DNS 解析时间，它和带宽无关。
Android/iOS 平台差异会让带宽判断更复杂
不同系统对「网络就绪」的定义不同，直接影响你测出的数值可信度：
- iOS 在未获取定位权限时，
networkType常为'unknown'或'none'，哪怕 WiFi 已连且能上网 —— 必须提前引导用户开NSLocationWhenInUseUsageDescription - Android 12+ 对后台网络访问有严格限制，App 切后台后
uni.request可能直接失败或超时，导致误判为“带宽归零” - 华为 EMUI、小米 MIUI 等定制 ROM 会主动丢弃非前台 App 的 TCP 包，造成测速结果严重偏低甚至超时
所以，所有带宽相关逻辑必须加兜底：只在 getCurrentPages().pop()?.route 是当前活跃页时才执行探测，且默认按「前台可用」处理，后台一律跳过。
别碰 uni.getConnectedWifi 试图取信号强度
这个 API 在 iOS 上需开启定位 + WiFi 权限，且仅返回 SSID/BSSID，不返回 RSSI；Android 部分机型（尤其 Android 10+）因隐私限制根本拿不到信号值。即使拿到 RSSI，它和实际带宽也非线性关系 —— -60dBm 的 WiFi 可能被千兆光纤拖垮，-85dBm 的 5G 也可能跑满 100Mbps。
真要监控带宽质量，唯一靠谱路径是：用 uni.request 定期打点 + 自定义阈值告警 + 页面状态联动（比如视频页自动切标清）。别指望框架 API 替你做这事。
