document.visibilitystate 返回 hidden 不一定表示页面切到后台，可能是浏览器预加载、标签休眠或冻结所致；应监听 visibilitychange 事件而非单次读取，并注意 ios safari 兼容性及 ssr 场景下的 undefined 问题。
document.visibilityState 返回 hidden 却没切到后台？
多数情况是页面被 Chrome 的「预加载」或 Firefox 的「标签休眠」机制干扰，不是代码写错了。visibilityState 只反映浏览器当前对页面可见性的判定，不保证用户物理上是否真在看。
-
visibilityState为"hidden"时，页面可能只是被最小化、切换标签、锁屏，也可能是被浏览器主动冻结（如 Chrome 闲置标签页） - 某些安卓 WebView 或 Electron 环境下，
visibilityState长期卡在"visible"，需配合document.hasFocus()和pageHide事件交叉验证 - 不要依赖单次读取
document.visibilityState做关键逻辑，比如暂停视频、停掉心跳请求——必须监听visibilitychange事件
addEventListener('visibilitychange') 不触发？
最常见原因是监听加得太晚，或者绑定在了错误的作用域里。这个事件只在 document 上触发，且必须在 DOM 加载后注册。
- 确保代码不在
DOMContentLoaded之前执行；若用模块打包，注意import顺序和执行时机 - 避免在 iframe 子页面中监听父页面的 visibilitychange——子页面有自己的
document，只能监听自身状态 - 某些 PWA 场景下，Service Worker 拦截了页面生命周期，导致事件延迟或丢失，建议加一层
setTimeout容错（例如 100ms 后再检查一次visibilityState）
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
stopAnimation();
} else if (document.visibilityState === 'visible') {
resumeAnimation();
}
});
visibilitychange 在 iOS Safari 中表现异常？
iOS Safari 对 visibilitychange 的触发非常保守：App 切到后台、锁屏、甚至双击 Home 键唤出多任务界面，都可能不发事件。这是系统级限制，无法绕过。
- 不能单独靠
visibilitychange实现 iOS 上的「页面不可见即暂停」逻辑 - 可组合使用
blur+focus（窗口级）、pagehide+pageshow（页面级），但要注意pagehide在 iOS 上也可能延迟数秒才触发 - 若业务强依赖可见性判断（如直播计时、答题倒计时），建议服务端同步心跳，并以最后一次有效心跳时间 + 客户端本地偏差作为兜底依据
visibilityState 与 prerender / loading 状态混淆？
visibilityState 永远不会是 "prerender" 或 "loading" —— 这两个值在现代浏览器中已被废弃，Chrome 自 56 起移除，Firefox 从未支持。现在只有 "visible"、"hidden"、"prerender"（仅旧版兼容残留）三种可能，而实际能拿到的只有前两个。
立即学习“前端免费学习笔记（深入）”；
- 检查代码里是否还保留类似
if (state === 'prerender')的分支，它们永远不会进入，纯属冗余 - 想判断页面是否完成加载，用
document.readyState或load事件，别混进 visibility 逻辑里 - SSR 或 hydration 场景下，服务端渲染时
document.visibilityState是 undefined，客户端首次执行 JS 时才是初始值，注意 SSR/CSR 状态不一致问题
真正难处理的不是怎么读 visibilityState，而是它和真实用户行为之间那层模糊地带——浏览器策略变、OS 干预多、WebView 实现杂。留个心眼，别让它成为你逻辑链里那个“理所当然”的环节。
