onBackPress 仅监听物理返回键和导航栏左上角返回按钮，不触发 iOS 侧滑返回；通过 options.from 区分来源，from === 'backbutton' 才应拦截并 return true，否则无法阻止默认行为。
onBackPress 能监听哪些返回动作？
onBackPress 是 uni-app 中唯一能统一响应「物理返回键」和「导航栏左上角返回按钮」的生命周期钩子，但它**不触发 iOS 侧滑返回**——这是最常被忽略的事实。你写完 onBackPress 测试时发现 Android 正常、iOS 侧滑却没反应，不是代码错了，是机制限制。
它接收一个 options 对象，关键字段是 from：
-
from === 'backbutton'：明确表示来自物理键或导航栏按钮（Android/iOS 均覆盖） -
from === 'navigateBack'：说明是 JS 主动调用uni.navigateBack()触发的，此时通常不该拦截（否则会卡死页面栈）
所以别一上来就 return true 拦死所有来源；先判断 from，否则用户点右上角菜单里的“返回”也会失效。
怎么阻止返回并弹确认框？别漏掉 return true
想在离开前弹窗确认，核心就两步：调用 uni.showModal + 在 onBackPress 最后 return true。漏掉 return true，弹窗还没出来，页面已经退走了。
常见错误写法：
onBackPress() {
uni.showModal({ /* ... */ }); // 忘了 return true → 默认行为照常执行
}正确写法（带逻辑分支）：
onBackPress(options) {
if (options.from !== 'backbutton') return false; // 不处理 navigateBack 等来源
uni.showModal({
title: '提示',
content: '未保存，确定离开？',
success: (res) => {
if (res.confirm) uni.navigateBack(); // 用户点了确定才手动返回
// 如果点了取消，啥也不做，页面停留
}
});
return true; // ⚠️ 关键！必须写在这儿，否则拦截失败
}iOS 侧滑返回怎么补救？禁用比监听更可靠
iOS 侧滑手势根本不会进 onBackPress，官方也明确不支持监听。硬要“监听”，实际是自找麻烦——有兼容性坑、手势冲突、甚至影响 WebView 内嵌页滚动。
更务实的做法是：在 pages.json 里直接关掉它：
"style": {
"app-plus": {
"popGesture": "none" // 禁用侧滑返回
}
}这个配置只影响 App 端（即打包后的 iOS/Android），H5 和小程序不受影响。如果你的 App 需要侧滑体验，那得接受它绕过你的逻辑——这时候应把关键状态保存逻辑前置（比如输入时实时存 uni.setStorageSync），而不是依赖返回拦截。
Web-View 页面里按返回键，为什么跳不出去？
在 web-view 页面中，Android 物理返回键默认行为是：先尝试 WebView 内部后退（webview.canBack），只有无历史时才退出页面。但很多 H5 页面没用 history.pushState，导致 canBack 一直返回 false，结果直接退出整个 App 或跳到上一页，完全失控。
解决要点：
- 在
onBackPress里先拿到webview实例：this.$scope.$getAppWebview().children()[0] - 调用
webview.canBack()判断能否内部后退 - 能则
webview.back()；不能则根据业务决定是uni.navigateBack()还是plus.runtime.quit() - 最后一定
return true，否则系统会走默认逻辑（可能直接关掉整个 App）
这个逻辑必须写在 web-view 所在的 uni-app 页面里，不是 H5 里写 JS 就能生效。
真正难的不是写几行代码，而是分清「谁在触发返回」「平台是否支持监听」「拦截后该交给谁处理」。尤其是 from 字段的判断、return true 的位置、以及 iOS 侧滑这个死结——不提前踩过，上线后用户一滑就闪退，debug 要花半天。
