onshow是返回刷新的唯一可靠入口，因onload仅首次触发，而onshow每次页面显示（含返回、切前台、tab切换）均执行；需加标志位防重复请求、重置分页、加loading锁，并在h5端额外监听popstate。
onShow 是解决返回不刷新的唯一可靠入口，其他方案要么失效、要么治标不治本。
为什么 onLoad 不行，而 onShow 必须用
页面从下一页返回时，onLoad 根本不执行——它只在首次加载时触发。真正每次页面“可见”都会走的钩子是 onShow，包括：从详情页返回列表页、切后台再切回来、tabBar 切换到已缓存页。常见错误就是把全部数据请求逻辑堆在 onLoad 里，结果返回后界面还是旧的。
注意两个典型干扰项：
-
onReady只表示 DOM 渲染完成，不保证页面可见，不能替代onShow - 自定义导航栏（
navigationStyle: custom）会屏蔽原生返回按钮，若没在按钮里手动调uni.navigateBack()，onShow就不会触发
onShow 里怎么写才不翻车
直接把 onLoad 的请求代码搬进 onShow 是最常见错误，会导致首次进入发两次请求、分页状态错乱、loading 并发等。
正确做法是加控制逻辑：
- 用标志位避免重复请求：
this.dataLoaded = false在onLoad设为true，onShow里只在!this.dataLoaded时拉数据 - 重置分页/搜索状态：
this.page = 1、this.searchKey = ''必须显式写在onShow开头，否则返回后继续加载第 2 页，漏掉新数据 - 加 loading 锁防并发：
if (this.loading) return; this.loading = true，请求结束再设为false - H5 真机调试时，iOS 微信 WebView 可能延迟触发
onShow，不要靠setTimeout补救，先检查是否误用了custom导航栏却没调uni.navigateBack()
H5 端浏览器返回必须额外监听 popstate
uni-app H5 端的原生浏览器返回（点击左上角或按键盘 Alt+←）不走任何生命周期，onShow 也不会触发——这不是 bug，是浏览器机制决定的。
唯一稳定捕获方式是监听 popstate：
- 必须在
onLoad或onShow中注册：window.addEventListener('popstate', this.handlePopState) - 必须在
onUnload或onHide中移除：window.removeEventListener('popstate', this.handlePopState)，否则多个页面实例会堆叠监听器 -
popstate事件对象不带方向信息，无法区分“返回”还是“前进”，只能靠自己维护路由栈快照做粗略判断 - 别试图用
beforeunload或拦截history.back()，H5 下基本无效，且 iOS Safari 上极易失效
只在编辑后刷新？用 eventChannel 或事件总线
不是每次返回都要刷新。比如从搜索页返回，应保留搜索结果；但从编辑页返回，才需要重载。这时 onShow 全局刷新就不合适了。
两种可控方案：
-
eventChannel：适合uni.navigateTo场景。A 页跳转时传events，B 页在onLoad中通过this.getOpenerEventChannel().emit()通知 A 页。注意：H5 不支持eventChannel，需降级为uni.setStorageSync+onShow轮询读取 - 全局事件总线：
uni.$emit('refreshList')和uni.$on('refreshList', ...)。关键点是：监听必须写在onLoad，卸载必须严格写在onUnload（不是onHide），且不能传匿名函数，否则uni.$off无法配对，导致内存泄漏和多次触发
别用 getCurrentPages() 手动取上一页实例再调方法——耦合高、H5 和小程序行为不一致、真机容易出错。
