onload仅首次触发是设计行为，返回应使用onshow刷新；但需防重复请求、竞态及h5缓存干扰，可加loading锁或用eventchannel定向通信，h5端还需监听popstate并配合query参数判断来源。
onLoad 本来就不该在返回时触发 —— 这是设计行为，不是 bug。 真正该用的是 onShow，但直接全塞进去容易重复请求、状态错乱。关键得看你要“刷新什么”“什么时候刷”“在哪端刷”。
为什么返回不执行 onLoad
uni-app 的 onLoad 只在页面**首次加载**（URL 进入或 uni.navigateTo 跳转）时执行一次；返回是复用已有实例，Vue 组件没销毁，所以生命周期不会重走 onLoad。这是跨平台（小程序/H5/App）统一行为，iOS 侧滑、Android 物理键、H5 浏览器回退都一样。
- 小程序：页面栈保留实例，
onLoad不重入 - H5：SPA 模式下路由复用组件，
onLoad不触发（created也不一定重走） - App：原生容器复用 Webview，
onLoad同样只首次执行
onShow 里拉数据的坑与对策
把数据请求从 onLoad 搬到 onShow 是最常见解法，但容易踩三个坑：
- 频繁触发：页面切后台再切回来、tabBar 切换、弹窗关闭后都会触发
onShow，导致无意义请求 - 竞态问题：快速来回切换页面，多个
onShow请求并发，后发先至，界面显示旧数据 - H5 缓存干扰：如果用了
<keep-alive></keep-alive>或浏览器级缓存，onShow可能没执行但 DOM 已“静止”
建议加一层控制：
onShow() {
if (this.loading || this.refreshLocked) return;
this.loading = true;
this.getData().finally(() => {
this.loading = false;
});
}
需要“仅返回时”才刷新？用 eventChannel 更可靠
如果只希望从详情页、编辑页等特定页面返回时才刷新（比如订单列表 → 支付页 → 返回），onShow 就太宽泛了。推荐用 eventChannel 做定向通信：
- 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 在 3.0+ 才稳定支持，低版本需降级为 uni.$emit/uni.$on，但要注意手动移除避免内存泄漏。
H5 端浏览器原生返回的特殊处理
H5 的 history.back() 或地址栏返回按钮，根本不会进 uni-app 生命周期，onUnload/onHide 都可能不触发。唯一稳定入口是 window.addEventListener('popstate')：
- 必须在
onLoad或onShow中注册，不能只在created - 必须在
onUnload或onHide中调用removeEventListener，否则监听器堆积 - 它不区分“返回”还是“前进”，只能靠自己维护路由栈长度或上一页路径做粗略判断
更务实的做法是：放弃拦截，专注在 onShow 里检查 document.hidden 或加个 from=detail query 参数，有则刷新。
真正容易被忽略的点是：不同端的“返回”本质不同 —— 小程序是框架内跳转，H5 是浏览器行为，App 是原生容器调度。不要试图写一套逻辑通吃，按端拆解、分层兜底才是稳的。
