visibilitychange 事件必须在 document 上监听且需手动校验初始状态，因 visibilityState 不反映真实用户焦点，iOS Safari 和 Chrome 存在兼容性陷阱，关键逻辑须结合 hasFocus()、pagehide/pageshow 交叉验证。
visibilitychange 事件必须监听，且仅在 document 上有效；单次读取 document.visibilityState 或 document.hidden 做业务判断，90% 会出错。
为什么 document.visibilityState === 'visible' 不代表用户真正在看
这个值反映的是浏览器的渲染调度策略，不是用户焦点快照。Chrome 可能因预渲染或标签页冻结返回 'visible'，而 iOS Safari 在锁屏/切后台后常卡在 'visible' 不变（尤其播放音频时）。反过来，'hidden' 可能只是标签页闲置被冻结，并非用户主动切换——关键逻辑如答题倒计时、直播心跳不能只靠它。
-
document.hasFocus()可辅助判断当前 tab 是否获得焦点（注意：iframe 内调用只反映子页面焦点） - 必须交叉验证
pagehide/pageshow：关闭标签页或刷新时，visibilitychange可能不触发，但pagehide一定触发 - SSR 渲染时
document不存在，直接访问会报undefined，需加存在性判断
visibilitychange 事件不触发的常见原因
这个事件只在 document 上触发，不冒泡、不委托，绑定错对象就等于没绑。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 监听写成
window.addEventListener('visibilitychange', ...)→ 无效 - 脚本放在
<head>顶部且无defer，DOM 未加载完就注册 → 漏掉首次状态变化（比如 Chrome 预加载标签页初始就是hidden） - 在 iframe 子页面里监听父页面可见性 → 子页面的
document和父页面完全隔离 - Service Worker 拦截生命周期，导致事件延迟或丢失（PWA 场景常见）
正确监听 + 初始状态校验的写法
必须先手动执行一次处理函数，再绑定事件——否则初始状态变化会被漏掉。
立即学习“前端免费学习笔记（深入）”；
document.addEventListener('DOMContentLoaded', () => {
const handleVisibilityChange = () => {
if (document.visibilityState === 'visible') {
console.log('页面回到前台');
// 恢复轮询、续播视频、重启动画
} else if (document.visibilityState === 'hidden') {
console.log('页面退到后台');
// 暂停定时器、停掉轮询、静音音频
}
};
// 先检查当前状态，防止漏掉初始状态
handleVisibilityChange();
document.addEventListener('visibilitychange', handleVisibilityChange);
});
- 避免在回调里直接操作大量 DOM 或触发重排，后台线程可能被降频甚至跳过渲染
- Chrome 88+ 对后台页面的
setTimeout/setInterval最低间隔强制为 1s，但visibilitychange本身仍能即时触发 - 某些 Android WebView 或微信内置浏览器锁屏后可能不触发
hidden，需用pagehide事件兜底
iOS Safari 是最大兼容性陷阱
双击 Home 键唤出多任务界面、App 切后台、甚至锁屏，都可能不触发 visibilitychange。这不是 bug，是系统限制。
- 页面正在播放音频时，iOS Safari 强制维持
document.visibilityState === 'visible'，哪怕用户已离开 - 不能把
document.hidden当开关控制定时器启停——该属性已被标记为“向后兼容”，现代浏览器推荐用visibilityState - 关键逻辑必须容错：加一层
setTimeout补漏（例如 100ms 后再检查document.hidden），或结合document.hasFocus()+pagehide综合判断
