应采用“快照+持续监听”双保险：在app.vue的onlaunch/onshow中调用uni.getnetworktype，在main.js或app.vue的created中尽早注册uni.onnetworkstatuschange；ios需注意其不触发kill后首次回调，且uni.opensetting无法跳转wi-fi设置页，须引导用户手动操作；弹窗需用全局变量防重复、区分错误类型、合理跳转；全屏断网组件需传入响应式isconnected数据并确保z-index足够高。
uni.getNetworkType 和 uni.onNetworkStatusChange 怎么用才不漏判
直接调用 uni.getNetworkType 只能拿到“快照”，比如 App 启动时查一次，但用户切后台再回来、Wi-Fi 切飞行模式，这个状态就 stale 了。真正可靠的方案是「快照 + 持续监听」双保险。
-
uni.getNetworkType放在App.vue的onLaunch和onShow里，确保每次前台可见都重读一次 -
uni.onNetworkStatusChange必须在全局尽早注册（比如main.js或App.vue的created），它不会自动销毁，也不依赖页面生命周期——这点很多人误以为要每个页面都写一遍 - 注意：iOS 上
uni.onNetworkStatusChange在 App 被 kill 后重启时不会触发首次回调，所以不能只靠它，必须配合getNetworkType初始化
断网弹窗为什么点“去设置”没反应？iOS 限制和 fallback 处理
iOS 系统明确禁止 App 直接跳转到「Wi-Fi 设置页」，uni.openSetting 实际打开的是当前 App 的权限设置页，不是网络设置。很多开发者卡在这一步，以为 API 失效了，其实是预期错了。
- 真机测试时，
uni.openSetting成功回调 ≠ 用户看到 Wi-Fi 页面；它只打开 App 自身设置，里面没有网络开关 - 正确做法：弹窗文案别写“前往网络设置”，改写为“前往系统设置 → 手动开启 Wi-Fi/蜂窝数据”
- Android 可用
uni.navigateTo({url: '/pages/settings/network'})自定义网络引导页；iOS 则建议加一句提示：“iOS 系统限制，需手动返回设置开启网络” - 千万别在
fail回调里静默吞错——加console.error，否则上线后完全无法定位问题
请求失败时重复弹窗、多页面冲突怎么防
网络请求封装层（比如 request.js）里直接调 uni.showToast 或 uni.showModal，很容易在快速切换页面、下拉刷新、tabBar 切换时触发多次弹窗，甚至弹出堆叠的 modal。
- 用一个全局变量
networkModalShow控制弹窗开关，设为true后不再重复触发 - 在弹窗
success回调里，记得延时 1 秒再重置networkModalShow = false，避免用户连点导致状态错乱 - 如果当前页面是 tabBar 页面，用
uni.reLaunch而非uni.redirectTo，否则可能跳进空白页（尤其在首页 tab 被缓存时） - 不要在
fail里无条件弹窗——先判断err.errMsg是否含"Network Error"或"timeout"，排除 token 过期等业务错误
全屏断网组件（fu-notwork）引入后不显示？常见配置陷阱
像 fu-notwork.vue 这类现成组件，看似开箱即用，但实际运行常因作用域或响应式失效而“隐身”。根本原因不是组件写得不好，而是它依赖外部传入的网络状态信号。
- 组件本身不主动调
uni.getNetworkType，它只监听isConnectedprop —— 你必须在父组件 data 里定义并实时更新这个值 - 别把
isConnected写成计算属性（computed），它需要被uni.onNetworkStatusChange回调修改，必须是响应式 data 字段 - z-index 默认 100 很可能被遮挡，尤其用了自定义导航栏或底部弹层时，建议设为
9999并加position: fixed - 图片用 base64 是为了离线可用，但如果组件按需加载（如异步 import），base64 图片路径可能解析失败，换成相对路径或 CDN 地址更稳
