document.visibilityState === 'visible' 不等于页面在前台，它仅反映浏览器渲染策略而非用户真实焦点；应监听 document 上的 visibilitychange 事件并校验初始状态，iOS Safari 中需结合 hasFocus() 和 pagehide 事件兜底。
document.visibilityState === 'visible' 不等于页面在前台
直接读取 document.visibilityState 判断是否“在前台”是常见误操作。它返回 'visible' 时，页面可能正被 iOS Safari 锁在前台（比如 App 切后台但音频仍在播放），也可能只是 Chrome 预渲染未完成的假可见状态；而返回 'hidden' 时，用户可能根本没切走——只是标签页闲置被 Chrome 冻结了。
这个值只反映浏览器对“是否该渲染/执行 JS”的策略判断，不是用户物理焦点的真实快照。真正可靠的入口只有一个：visibilitychange 事件，且必须配合初始状态校验。
必须监听 visibilitychange 事件，且不能漏掉首次触发
事件只在 document 上触发，不冒泡、不委托，绑定错对象就完全失效。常见错误包括：
- 脚本放在
顶部且无defer，DOM 还没加载完就注册监听 → 漏掉页面初始从prerender或hidden切到visible的第一次变化 - 监听写成
window.addEventListener('visibilitychange', ...)→ 无效，事件根本不在window上 - 在 iframe 子页面里试图监听父页面状态 → 子页面的
document和父页面无关
正确做法是确保 DOM 加载完成后执行，例如：
立即学习“前端免费学习笔记（深入）”；
document.addEventListener('DOMContentLoaded', () => {
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'visible') {
// 页面变为可见：恢复动画、重连心跳、续播视频
} else if (document.visibilityState === 'hidden') {
// 页面不可见：暂停计时器、停掉轮询、静音音频
}
});
});
iOS Safari 是最大兼容性陷阱
在 iOS Safari 中，visibilitychange 触发极其保守：
- 双击 Home 键唤出多任务界面 → 通常不触发
- App 切后台（甚至锁屏）→ 经常卡在
'visible'不变 - 页面正在播放音频 → 系统强制维持
'visible'，哪怕用户已离开
这意味着单靠 visibilityState 做关键逻辑（如答题倒计时、直播心跳）会严重失准。必须交叉验证：
- 用
document.hasFocus()辅助判断当前 tab 是否获得焦点（注意：iframe 内调用返回的是子页面焦点） - 监听
pagehide事件作为补充（但它在 iOS 上也可能延迟数秒才触发） - 强依赖场景建议服务端同步心跳，客户端以最后一次有效心跳时间 + 本地偏差为兜底依据
不要信任 document.hidden，也别碰已废弃的 prerender/unloaded
document.hidden 是旧 API，已被标记为废弃，现代浏览器虽仍支持，但语义模糊、行为不一致（尤其在 SSR 渲染或预加载环境下容易返回 undefined）。应统一使用 document.visibilityState。
另外，'prerender' 和 'unloaded' 在主流浏览器中基本已不可见：
- Chrome 自 56 版起移除
'prerender' - Firefox 从未支持
'prerender'和'unloaded' - 现在实际能稳定拿到的只有
'visible'和'hidden'
如果代码里还看到 if (document.visibilityState === 'prerender')，基本可以删掉——它不会被执行。
