Safari浏览器中H5页面的返回上一页历史不刷新问题该如何解决？
iOS/Safari中页面从bfcache恢复时JS冻结，需监听pageshow事件并检查event.persisted为true后执行reload；可配合服务端Cache-Control: no-store禁用bfcache或用location.replace替代history.back。
在Safari浏览器（尤其是iOS设备）中，用户点击返回按钮或执行history.back()后，页面内容和JavaScript状态常被Back-Forward Cache（bfcache）冻结，导致倒计时停摆、表单状态残留、新数据不显示——这不是代码没写，而是页面根本没重跑JS。
检测并仅对iOS/Safari触发刷新
第一步：用正则精准匹配iOS设备或Safari浏览器，避免安卓重复刷新。
第二步：监听pageshow事件，检查event.persisted是否为true——只有从bfcache恢复的页面才需要强制重载。
第三步：确认条件成立后，执行window.location.reload()。这一步必须放在if (event.persisted)内部，否则会无差别刷新，破坏安卓正常行为。
【关键点】不能直接监听load或DOMContentLoaded，它们在bfcache中根本不会触发；pageshow是唯一能稳定捕获“从缓存恢复”这一时刻的钩子。
兼容性更强的双保险写法
方法一：增加performance.navigation.type === 2判断（表示通过前进/后退进入页面），覆盖部分旧版iOS未正确设置persisted的情况。
方法二：把逻辑封装进立即执行函数，防止全局变量污染，同时兼容IE11以下环境（虽然已极少见，但内嵌WebView可能仍存在）。
方法三：将脚本放在<head>最底部或DOMContentLoaded回调中执行，确保监听器在页面任何交互前就位。
服务端配合禁用bfcache（可选）
在响应头中添加Cache-Control: no-store可让Safari彻底放弃缓存该页面，强制每次返回都走完整网络请求。
注意：no-cache或must-revalidate无效，只有no-store能真正阻止bfcache启用。
如果使用Nginx，配置为：add_header Cache-Control "no-store";；若为Node.js Express，则调用res.set("Cache-Control", "no-store")。
【不可逆操作】一旦设置了no-store，所有浏览器（包括Chrome/Firefox）都会禁用该页面的往返缓存，可能轻微影响返回速度，需权衡首屏性能与状态一致性。
替代方案：用location.replace跳转代替history.back
在跳转到下一页前，先用location.replace(document.referrer)替换当前历史记录，这样返回时就不会经过原页面缓存路径。
这招适合跳转链明确、且不需要保留中间页历史的场景（如表单提交后返回列表页）。
注意：它会抹除当前页在历史栈中的位置，用户无法再从目标页按两次返回回到本页——只适用于“单向返回”需求。
