HTML页面生命周期钩子在Blink、WebKit、Gecko内核中行为差异显著：bfcache策略不同导致pageshow/pagehide触发逻辑和persisted值不一致；beforeunload兼容性差，Safari静默忽略、Firefox限制多；unload已不可靠；visibilitychange判定粒度各异；DOMContentLoaded不保证CSSOM就绪。
HTML 页面生命周期钩子（如 pageshow、pagehide、beforeunload、unload）在不同浏览器内核（Blink/V8、WebKit/JavaScriptCore、Gecko/SpiderMonkey）下行为不一致，不是“写一次就跑通”的事情。最常踩的坑是：你以为页面隐藏了，其实只是被冻结；你以为能弹窗拦截离开，其实 Safari 已静默丢弃 beforeunload；你以为 pageshow 总是触发，结果 Firefox 在 bfcache 失效时根本不会调用。
pageshow/pagehide 在 bfcache 场景下的触发逻辑差异
这两个事件是否触发、是否带 persisted: true，取决于浏览器是否启用 bfcache（back-forward cache），而各内核策略完全不同：
- V8（Chrome/Edge）：默认启用 bfcache，但对含
beforeunload监听器、pagehide中执行同步 fetch、或使用 Web Locks API 的页面会主动排除；pageshow在从 bfcache 恢复时必触发，persisted为true - JavaScriptCore（Safari）：bfcache 更激进，连
beforeunload监听器都不一定导致排除，但一旦页面进入 bfcache，pagehide后不再触发unload；pageshow触发时persisted几乎总是true，且恢复极快 - SpiderMonkey（Firefox）：bfcache 默认关闭（2026 年仍需手动开启
dom.bfcache.enable_for_test），多数用户实际走的是传统卸载路径；pageshow仅在显式前进/后退且缓存命中时触发，persisted值不可靠
实操建议：不要依赖 pageshow 初始化状态，它可能复用旧 DOM；需检查 event.persisted 并做差异化处理，例如：
window.addEventListener('pageshow', (e) => {
if (e.persisted) {
// 从缓存恢复：重置定时器、刷新过期数据、重绑事件（部分监听器可能失效）
resetUI();
} else {
// 全新加载：执行完整初始化
initApp();
}
});
beforeunload 和 unload 的兼容性断层
beforeunload 是唯一允许同步弹出提示的钩子，但各内核对其拦截和触发时机的解释天差地别：
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- V8：仅当用户主动触发导航（点击链接、输入 URL、前进/后退）时触发；SPA 路由跳转（如 Vue Router 的
router.push）默认不触发；返回 false 或 return 字符串已废弃，现只支持event.preventDefault()（且仅限用户手势触发） - JavaScriptCore：自 Safari 15.4 起，
beforeunload在非用户手势（如定时器、fetch 回调）中完全被忽略；且弹窗提示文案由系统统一控制，无法自定义 - SpiderMonkey：仍支持
return 'string'触发提示，但仅对顶层导航生效；iframe 内页面的beforeunload基本无效；unload事件在 bfcache 禁用时才稳定触发
关键陷阱：unload 在现代浏览器中几乎不可靠——Safari 17+ 和 Chrome 120+ 已移除其大部分能力（如无法发起网络请求、无法读取 localStorage），仅剩极简清理逻辑可用。不要在里面调用 fetch 或 IndexedDB。
visibilitychange 与 page visibility API 的引擎级偏差
visibilitychange 事件看似标准，但各内核对“页面可见性”的判定粒度不同，尤其影响 PWA 和音视频场景：
- V8：标签页失焦即触发
visibilityState = 'hidden'，哪怕只是被另一个窗口遮挡；但若页面在后台运行 Service Worker，visibilityState可能长期保持'visible'（误导性） - JavaScriptCore：iOS Safari 对 WebView 的 visibility 判定更保守——App 进入后台时才触发
hidden，切到其他 Tab 不一定触发；且document.hidden在 WKWebView 中可能延迟数百毫秒更新 - SpiderMonkey：严格遵循规范，但
visibilitychange在私密浏览模式下会被静默抑制，且visibilityState在页面被挂起（如 Android 后台）时可能卡在'prerender'状态
实操建议：音视频自动暂停逻辑必须同时监听 visibilitychange 和 pagehide，并用 document.hasFocus() 辅助判断；不要单靠 document.hidden 决定资源释放时机。
DOMContentLoaded 与解析完成的引擎判定边界
DOMContentLoaded 表面一致，但各内核对“DOM 解析完成”的定义存在细微差别，尤其影响 SSR 和 hydration：
- V8：严格按 HTML 解析流执行，
<script defer></script>不阻塞该事件；但若存在未 resolve 的document.open()调用，事件可能永久不触发 - JavaScriptCore：对
<template></template>标签内容的解析计入 DOM 构建，但若模板内含未闭合标签，可能延迟事件触发；且在 WebKit 17+ 中，DOMContentLoaded会在所有<link rel="stylesheet">加载完毕后才触发（V8 不强制） - SpiderMonkey：对
<script type="module"></script>的依赖解析更早介入，可能导致事件在模块脚本尚未执行前就触发；且对document.write()的容错更强，不易卡死
真正容易被忽略的是：这个事件不保证 CSSOM 就绪，也不代表图片/字体已加载。如果你在回调里读取 getBoundingClientRect()，在 Safari 下可能拿到 0 值——因为样式尚未应用。
