先说说 iOS/Safari 里一个挺常见的坑。

用户点完返回按钮，或者通过 history.back() 回到某个页面，结果发现倒计时停了、表单里填的东西还在、新数据压根没刷出来。

别急着怀疑代码写错了——问题出在 Safari 的 Back-Forward Cache（bfcache）上。这玩意儿会把页面“冻住”，JS 压根儿没机会重跑一次。

换句话说，不是你的逻辑有问题，是页面根本没重新执行。

检测并仅对 iOS/Safari 触发刷新

解决思路其实很直白：精准锁定 Safari 或者 iOS 设备，然后在页面从 bfcache 恢复时，强制让它重新加载一次。

第一步，用正则匹配，确保只有 iOS 或是 Safari 浏览器会被触发。

别误伤了安卓或者其他内核的正常行为。

第二步，监听 pageshow 事件。这个事件是唯一能在页面从 bfcache 恢复时稳定触发的东西。

判断条件就是看 event.persisted 是不是 true——只有从缓存恢复的页面，这个值才会被设置为真。

第三步，条件成立，执行 window.location.reload()。

注意：这一步必须放在 if (event.persisted) 的内部，否则就成了无差别刷新，安卓那边的正常表现会被破坏。

关键在这里：别指望 load 或者 DOMContentLoaded 能解决问题。这两个事件在 bfcache 状态下根本不会触发。pageshow 才是那个绕不开的钩子。

兼容性更强的双保险写法

如果想把兼容性做得更稳一点，可以叠几层判断。

比如，加上 performance.navigation.type === 2 的检查。这个值表示用户是通过前进/后退进入页面的。

在某些旧版 iOS 上，persisted 可能没有正确设置，加上这个判断可以兜底。

另外，建议把逻辑封装进一个立即执行函数里。这样既避免全局变量污染，也能兼容一些老旧的浏览器环境——比如某些内嵌 WebView，虽然少见，但保不齐会遇到。

还有一个小细节：把脚本放在 的最底部，或者放在 DOMContentLoaded 回调里执行。这样能保证监听器在任何用户交互之前就已经就位，不会漏掉任何一次缓存恢复。

服务端配合禁用 bfcache（可选）

如果你想把问题彻底扼杀在源头，还有一个更粗暴的办法：直接让服务端告诉 Safari，这个页面不值得缓存。

具体做法是，在响应头里加上 Cache-Control: no-store。

注意：这里必须是 no-store。用 no-cache 或者 must-revalidate 都没用，Safari 仍然会把页面塞进 bfcache。只有 no-store 才能真正让 Safari 放弃缓存。

配置方式也很简单：

• 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) 替换当前的历史记录。这样一来，用户再按返回键，就不会经过原页面的缓存路径了。

这个方法的代价也很清楚：它会抹掉当前页在历史栈中的位置。用户从目标页按两次返回，是无法再回到本页的。所以它只适合那种“单向返回”的需求。

《夸克》非常好用的免费AI浏览器

下载APP查看