本文深入解析了如何准确识别浏览器 BFCache（Back/Forward Cache）页面恢复场景，强调必须在 `window.onpageshow` 事件中通过 `event.persisted === true` 进行唯一可靠的判断——此时页面完全复用原有 DOM、JS 上下文、定时器和滚动位置，而 `mounted`、`DOMContentLoaded` 和 `load` 等常规生命周期钩子根本不会触发；文章还澄清了 `pagehide` 中 `persisted` 恒为 `undefined` 的常见误区，并提供了 iOS/安卓兼容性差异下的实用兜底方案（如 `performance.getEntriesByType` 和 `window.name`），同时警示了重置逻辑误放、状态误判及内存泄漏等高频陷阱，帮助开发者真正实现平滑、健壮的缓存感知式页面行为控制。

直接看 event.persisted 就行——为 true 表示页面是从 BFCache 恢复的，此时 DOM、JS 执行上下文、定时器、滚动位置等全部保持原样，不会重新执行 mounted、DOMContentLoaded 或 load。

核心判断逻辑必须放在 pageshow 里

不能在组件挂载或 DOM 加载完成时做重置，因为 BFCache 页面根本不会触发这些钩子。只有 pageshow 是唯一可靠入口：

• 监听 window.addEventListener('pageshow', handler)，且需在页面生命周期早期注册（如脚本顶部或 onMounted 中）
• 在回调中检查 event.persisted === true，成立即代表“热恢复”，不是新加载
• 此时可手动重置表单、刷新数据、重置状态变量，或调用 location.reload()（慎用，会丢 JS 状态）

别误用 pagehide 的 persisted 属性

pagehide 事件里的 event.persisted 始终是 undefined，该属性只在 pageshow 中有效。拿它做判断一定会失效。

移动端兼容性与兜底建议

iOS Safari 和微信 WebView 对 BFCache 支持较好，但部分安卓 WebView 可能不支持或行为不一致：

• 可结合 performance.getEntriesByType('navigation')?.[0]?.type === 'back_forward' 辅助识别后退/前进导航
• 若需更高确定性，可用 window.name 标记跨刷新状态（它在同源 tab 内不随 BFCache 清除）
• 避免用 sessionStorage 判断刷新，它在 BFCache 恢复时可能残留，导致误判

常见误操作提醒

很多问题源于对事件触发时机理解偏差：

• 不要在 pageshow 里无条件执行重置——先判断 persisted，否则首次加载也会被干扰
• 不要在 onload 或 mounted 里调用数据拉取并期望它覆盖缓存状态，BFCache 下这些钩子压根不执行
• 监听器记得在页面卸载前移除（如 onBeforeUnmount），防止内存泄漏

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~