onHide 是 uni-app 中最后一个可靠生命周期钩子，仅表示进入后台而非真正退出；它无法捕获进程被系统强杀等场景，需在此保存状态、清理定时器；iOS/Android 均未提供 JS 层“进程终止”回调。
onHide 能监听到后台切换，但不是“退出”
uni-app 的 onHide 确实会在用户按 Home 键、切到其他 App、锁屏等场景下触发，但它只代表“进入后台”，**不等于进程被终止或应用真正退出**。Android 强杀、iOS 冷启动前的内存回收、低内存自动清理——这些都不会再触发任何 JS 生命周期钩子。
-
onHide是你能拿到的最后一个可靠信号，必须在这里做状态保存、定时器清理、心跳停发 - 别在
onHide里发“我已退出”的上报，它可能几分钟后又切回前台，你报的是假退出 - iOS 后台 JS 执行权极不可靠：
setInterval和setTimeout在后台大概率被系统暂停（尤其 iOS 15+），别指望靠它维持长连接或轮询
为什么没有 onExit 或 onTerminate？
这不是 uni-app 的缺陷，而是所有跨平台框架（React Native、Flutter、Taro）都面对的原生限制：**iOS 和 Android 均未向 JS 层暴露“进程即将被杀死”的回调接口**。系统决定回收时，JS 上下文直接被销毁，连 onError 都来不及触发。
- Android 的
onTaskRemoved或onDestroy属于原生 Activity 生命周期，JS 层无法同步感知 - iOS 的
applicationWillTerminate:只在极少数冷启动前触发，且无 JS 绑定机制 - uni-app 的
onHide+ 原生插件（如 plus.runtime.quit）是目前最接近“退出前动作”的组合，但 quit 是主动调用，不是监听
想“模拟退出行为”，得结合平台特性补位
如果业务强依赖“退出前保存/上报”，只能绕过 JS 生命周期，借助原生能力兜底：
- Android：在
manifest.json中配置前台服务权限，并用原生插件监听onTaskRemoved，在 service 中执行清理逻辑 - iOS：无法监听终止，但可在
onHide后启动一个本地通知（带时间戳），下次onLaunch时比对时间差，若间隔 >5 分钟，可近似认为上次是“非正常退出” - 通用策略：所有关键状态（如表单草稿、播放进度）应在变更时立即持久化（
uni.setStorageSync），而不是等到onHide才存——因为onHide可能根本没机会执行
onShow 的陷阱：它不区分“冷启动”和“热切回”
onShow 在两种完全不同的场景下都会触发：一是从桌面冷启动 App，二是从微信切回来。但 uni-app 没有提供参数让你区分这两者，所以不能默认“一进前台就刷新全部数据”。
- 冷启动时
onShow后通常跟着onLaunch（仅首次），但热切回只有onShow - 建议用时间戳 + 缓存标记判断：在
onHide存一个lastHideTime，onShow读取并计算差值，>30 秒再触发重登录或全量刷新 - 别在
onShow里调uni.login或uni.checkSession，频繁触发会触发微信风控
onHide 当作最后防线，把关键状态写死到本地，其余交给系统。 
