应使用 onshow 替代 onload 实现返回刷新，因 onload 仅首次触发；需更新数据时统一放 onshow，必要时结合 eventchannel 或全局状态管理，并注意 h5 和 app 端差异。
uni.navigateTo 之后返回不刷新？用 onShow 替代 onLoad
页面跳转后返回不触发 onLoad，这是预期行为——onLoad 只在首次加载时执行。真正该监听的是 onShow，它每次页面显示都会触发，包括从其他页面返回、后台切前台等场景。
常见错误是把数据拉取逻辑全塞进 onLoad，结果返回时界面还是旧数据。实际项目里，只要涉及“返回需更新”的场景（比如订单页跳转支付页再回来），一律改用 onShow。
-
onShow每次显示都执行，适合刷新列表、检查登录态、同步状态 - 如果只希望“返回时”才刷新（而非所有显示），可用
getCurrentPages()判断上一页是否目标页面，但多数情况没必要过度判断 - 注意：频繁请求建议加节流或 loading 锁，避免快速切换导致重复请求
跨页面传参 + 返回刷新的可靠组合：uni.navigateBack 配合 eventChannel
从 A 页跳到 B 页，在 B 页操作完成后主动通知 A 页刷新，比轮询或全局事件更可控。uni-app 3.0+ 推荐用 eventChannel 实现单向通信。
关键点在于：A 页跳转时创建 channel，B 页通过 eventChannel.emit 触发，A 页在 onLoad 里监听 —— 注意不是 onShow，因为 channel 只在首次加载时可绑定。
- A 页跳转：
uni.navigateTo({ url: '/pages/b/b', events: { refresh: () => { this.getData() } } }) - B 页返回前：
this.getOpenerEventChannel().emit('refresh') - 必须在 A 页
onLoad中调用this.getOpenerEventChannel().on('refresh', ...)，延迟到onShow会失效 - 不支持 H5 端的
eventChannel（H5 无 opener 概念），需降级为uni.setStorageSync+onShow轮询读取
全局监听路由变化？别用 uni.addInterceptor 拦截跳转
有人想统一处理所有跳转/返回，试图用 uni.addInterceptor('navigateTo') 或监听 onPageScroll，这不可靠。uni-app 的路由拦截器不覆盖返回、tabBar 切换、下拉刷新等行为，且无法感知页面卸载时机。
真正能稳定捕获“页面显隐”的，只有生命周期钩子本身。所谓“全局监听”，本质是每个页面都实现一遍 onShow/onHide，或封装成 mixin：
- 新建
mixins/page-lifecycle.js，导出onShow回调逻辑 - 在需要响应的页面中引入：
mixins: [require('@/mixins/page-lifecycle.js')] - 避免在 mixin 里直接写业务请求，应暴露钩子函数供页面自行决定何时调用
- App 端原生 tabbar 页面的
onShow在 iOS 上有延迟（约 100ms），如需立即响应，可结合plus.navigator.getStatusBarHeight()等空操作触发重绘
H5 和小程序表现不一致？重点查 uni.navigateBack 的 delta 参数
H5 端 uni.navigateBack({ delta: 1 }) 行为和小程序不同：H5 会强制走浏览器 history.back()，若历史栈不足（比如从分享链接直接进入），可能静默失败且不报错；小程序则会 fallback 到首页。
真实项目里，返回刷新失败往往卡在这儿。不要假设 delta 总是安全的：
- 先用
getCurrentPages().length判断当前栈深，再决定 delta 值 - H5 下建议优先用
uni.navigateBack({ url: '/pages/a/a' })显式跳转，避免依赖栈深 - App 端要注意：nvue 页面不支持
eventChannel，跨 nvue 和 vue 页面通信得用uni.$emit/uni.$on，但需手动清理避免内存泄漏
最麻烦的其实是 tabBar 页面——它们不会触发 onUnload，onShow 也只在首次显示时准，后续切换靠 onTabItemTap。这个细节，很多人调试半天才发现没监听对地方。
