uni.onNetworkStatusChange 是 App 端检测网络状态变化的唯一可靠入口，但需自行处理防抖、权限、上下文丢失等问题；它仅在系统网络栈切换时触发，非轮询，且在 iOS 后台、Android 定制 ROM 等场景易失效。

uni.onNetworkStatusChange 是 App 端检测网络状态变化的唯一可靠入口，但它不等于“断网提醒”开箱即用——你得自己处理 isConnected: false 的触发时机、防抖、页面上下文丢失、以及真机权限缺失等实际问题。

uni.onNetworkStatusChange 为什么在App里有时不触发

它只在系统网络栈真正切换时回调，不是轮询。常见失效场景：

• App 启动后没调用 onShow 就直接进页面，监听未注册（必须在 onShow 中注册才稳定）
• iOS 真机调试未开启「后台运行」权限，切到桌面后监听立即失效
• Android 某些定制 ROM（如华为 EMUI）会限制后台网络广播，需手动在 manifest 中补 android.permission.ACCESS_NETWORK_STATE
• WiFi 已连接但 DHCP 还没分配 IP，isConnected 仍为 false，此时用户看到的是“断网”，其实只是延迟

如何避免“断网弹窗狂轰滥炸”

网络抖动（比如地铁穿隧道）会导致 isConnected 在 true/false 间快速跳变，直接弹窗会把用户吓退。实操建议：

• 加 1.5 秒防抖：用 setTimeout 缓存上一次 isConnected 值，仅当连续 2 次为 false 才触发提醒
• 限制单日弹窗次数（例如最多 3 次），用 uni.getStorageSync('offline_count') + 时间戳判断
• 只在当前页面是活跃页（getCurrentPages().pop()?.route === 'pages/xxx'）时才 showToast，避免后台页误触
• 别用 uni.showModal 做首次断网提示——阻塞操作，用户点“确定”前无法做任何事；优先用 uni.showToast 或顶部 banner

uni.getNetworkType 能否替代实时监听

不能。它是快照，适合页面加载时兜底判断，但有明显缺陷：

uni-app

uni-app 是基于 Vue 的跨端开发框架，适合开发 H5、App、小程序、鸿蒙和多端业务应用。

下载

• 冷启动时安卓部分机型返回 unknown（网络栈未就绪）
• iOS 在无网络下可能卡住 2–3 秒才回调，导致页面白屏等待
• 即使返回 wifi，也不代表能通外网（比如公司内网 WiFi 无公网出口）
• 必须搭配 uni.onNetworkStatusChange 使用：前者做初始状态，后者做持续响应

推荐组合写法：uni.getNetworkType 获取初始值 → 存入全局 Vue.prototype.$network → 在 onShow 中注册 uni.onNetworkStatusChange 更新该值 → 所有页面 watch 它即可响应

断网后要不要自动重试请求

不要无条件重试。真实项目中容易忽略的关键点：

• 断网期间积压的请求（比如离线提交的表单）应进队列，但需标记时间戳，超 5 分钟未恢复则丢弃，避免网络恢复后集中爆发请求打崩服务端
• 重试逻辑必须和具体 API 绑定，而不是全局拦截 —— 登录接口断网后重试有意义，但上传大文件中途断网再重试大概率失败
• H5 环境下 uni.onNetworkStatusChange 不工作，必须 fallback 到 navigator.onLine + 定期 uni.request 心跳探测（如每 15 秒 GET /health）
• App 后台被杀后重启，之前监听已丢失，需在 onLaunch 和 onShow 都重新注册监听

最常被绕过的细节是：iOS 上用户手动关闭 WiFi 开关后，isConnected 可能延迟 1–2 秒才变为 false；而 Android 某些厂商（如小米）会在省电模式下直接禁掉网络状态广播 —— 这时候你得靠心跳请求兜底，不能只信 API 返回值。