h5返回不触发onshow是因浏览器或uni-app缓存导致，应将数据加载逻辑统一放在onshow中，并结合visibilitychange监听与延迟校验确保刷新。
uni-app H5 返回不触发 onShow？检查页面是否被缓存
页面“看起来没刷新”，大概率是 onShow 没执行，而不是数据没更新。H5 端页面可能被浏览器或 uni-app 自身缓存，导致 created、onLoad 不重跑，onShow 也没触发——尤其在 iOS Safari 和微信内置浏览器中常见。
必须确保：在 onLoad 或 onShow 中注册监听，不能只在 created；onUnload 或 onHide 中移除监听，否则多个页面实例会堆积 popstate 监听器。
-
onShow是唯一可靠的数据刷新入口，所有动态数据加载逻辑必须放在这里（不是onLoad） - 如果用了
<keep-alive></keep-alive>包裹组件（H5 不推荐），activated钩子会替代onShow，需同步检查 - 微信浏览器可能启用“页面可见性优化”，可加
document.addEventListener('visibilitychange')辅助判断
为什么 history.back() 后页面 DOM 还是旧的？这不是 bug，是 keep-alive 行为
用户点浏览器返回按钮后，DOM 没变、data 还是上次的值——这其实是预期行为。Vue 实例未销毁，keep-alive 或 uni-app 页面复用机制让组件状态保留，onShow 才是你该响应的时机。
别试图用 location.reload() 强刷，它破坏 history 栈、白屏明显、iOS 上还可能触发二次加载。
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
- 真正要做的不是“刷新页面”，而是“重拉关键数据”：在
onShow中调用 API、重置表单字段、清空临时缓存 - 可加时间戳或版本号判断是否需要更新，避免无意义请求：
if (Date.now() - this.lastFetched > 30 * 1000) { this.fetchData() } - 若依赖上一页传参（如订单 ID），建议通过 URL query 透传，而非 rely on 页面栈或全局变量
uni.navigateBack() 在返回时静默失败？页面栈已丢失
H5 刷新后 getCurrentPages().length === 1，此时调用 uni.navigateBack() 会直接静默失败，不会报错也不会跳转——这是设计使然，不是你写错了。
所有自定义返回按钮、左上角返回逻辑，必须封装一层兜底判断，不能直接裸调 uni.navigateBack。
- 用
safeNavigateBack封装：先查getCurrentPages().length，≤1 时降级为history.go(-1) - 注意
history.go(-1)可能跳到第三方页面（比如支付回调页），上线前务必实测完整路径流 - 不要在
onUnload存页面栈——H5 刷新时这个生命周期根本不会触发
iOS Safari 返回不触发 onShow？加 visibilitychange + 延迟重载策略
iOS Safari 对 SPA 的 back/forward 缓存（bfcache）特别激进，有时连 popstate 都不触发，onShow 彻底失联。这不是 uni-app 能控制的底层限制。
可行对策是组合检测：监听 visibilitychange + 页面可见时延迟 100ms 主动触发一次数据校验。
- 在
onLoad注册：document.addEventListener('visibilitychange', () => { if (!document.hidden) setTimeout(() => this.checkAndRefresh(), 100) }) -
checkAndRefresh()中比对当前 URL、query 参数或本地存储的 lastSeenRoute，判断是否需要重拉 - 慎用
pagehide/pageshow：iOS 上它们触发不稳定，且pageshow的event.persisted并不可靠
