必须监听 visibilitychange 事件并校验初始状态，因单次读取 document.visibilityState 90% 出错；该事件仅在 document 上触发、不冒泡，常见失效原因包括绑定对象错误、脚本执行过早、iframe 隔离、Service Worker 干扰等。
单次读取 document.visibilityState 做业务判断，90% 会出错——必须监听 visibilitychange 事件，并手动校验初始状态。
为什么 visibilitychange 事件不触发？
这个事件只在 document 上触发，不冒泡、不委托，绑定错对象就等于没绑。常见失效原因包括：
- 监听写成了
window.addEventListener('visibilitychange', ...)或某个 DOM 节点上 - 脚本放在
<head>顶部且无defer，DOM 还没加载完就注册 → 漏掉首次状态变化 - 在 iframe 子页面里试图监听父页面的可见性 → 子页面的
document和父页面无关 - Service Worker 拦截生命周期，导致事件延迟或丢失（PWA 场景常见）
容错建议：加一层 setTimeout 补漏，例如 100ms 后检查 document.hidden 状态。
document.visibilityState === 'visible' 就代表用户在看？
不是。这个值只反映浏览器渲染策略，不是用户真实焦点快照：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 中，App 切后台或锁屏后，
visibilityState经常卡在'visible'不动（尤其播放音频时） - Chrome 冻结闲置标签页、Firefox 休眠标签、Edge 预渲染都会让状态变成
'hidden'，但用户根本没切走 - SSR 渲染时，服务端没有
document，直接访问会报undefined
关键逻辑（如答题倒计时、直播心跳）不能只依赖它，必须交叉验证：document.hasFocus() + pagehide / pageshow 事件。
轮播图/动画该不该用 visibilityState 控制启停？
别直接用。它管的是“整个页面是否被用户聚焦”，和元素是否在视口内完全无关：
- 用户滚动离开轮播区域，但页面仍处于
'visible'状态 → 动画还在跑，浪费资源 - 轮播图在折叠面板里默认隐藏，
visibilityState仍是'visible'→ 无法触发暂停 -
IntersectionObserver更准、更轻量，且兼容性已覆盖所有现代环境
示例中只需监听轮播容器是否进入视口，而不是等整个页面切走才响应：
const carouselEl = document.querySelector('.carousel');
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
startAutoPlay();
} else {
stopAutoPlay();
}
});
}, { threshold: 0 });
observer.observe(carouselEl);
iOS Safari 是最大兼容性陷阱
它的行为不是 bug，是系统级限制，没法绕过：
- 双击 Home 键唤出多任务界面 → 通常不触发
visibilitychange - App 切后台、锁屏、甚至播放静音视频 →
visibilityState仍为'visible' -
pagehide在 iOS 上也可能延迟数秒才触发，不能当作即时信号
真机测试必不可少；模拟器或桌面 Safari 行为差异极大。强依赖可见性的业务（比如考试系统），建议服务端同步心跳，并以最后一次有效心跳时间 + 客户端本地偏差作为兜底依据。
