document.visibilityState 是 HTML5 Page Visibility API 提供的只读属性，返回 "visible"、"hidden"、"prerender" 或 "unloaded" 四种状态值，用于反映页面在浏览器中的可见性；它能较准确检测标签页切换、窗口最小化、锁屏等隐藏场景，但在 iOS Safari 后台标签页中可能滞留 "visible"，且无法识别窗口被其他应用遮挡的情况，因此适用于“大概率暂停”而非绝对精确的隐藏判断。
document.visibilityState 是什么，它能准确反映页面是否被隐藏吗
document.visibilityState 是浏览器原生提供的页面可见性 API，返回 "visible"、"hidden"、"prerender" 或 "unloaded"。它比 blur/focus 更可靠——比如用户切换到其他标签页、最小化窗口、锁屏，甚至某些安卓后台 WebView 场景下，都能触发 "hidden"；而 blur 在 Chrome 新标签页或部分移动端并不稳定。
但它不是万能的：visibilityState 在 iOS Safari 的某些后台 tab 中可能长期卡在 "visible"（尤其未启用 background-fetch 时），且无法感知用户是否只是遮挡了浏览器窗口（如弹出全屏应用）。所以它适合“大概率暂停”，不能替代服务端心跳保活逻辑。
如何用 visibilitychange 事件正确绑定并清理定时器
监听必须用 document.addEventListener('visibilitychange', ...)，且建议在初始化时就注册，避免漏掉首次状态变化。关键点是：不要在回调里直接调用 clearInterval 或 clearTimeout，而应提前把所有需要控制的定时器 ID 存进一个数组或 Map 中，统一管理。
- 用
WeakMap或全局数组存定时器 ID，避免内存泄漏（尤其组件反复挂载/卸载时） - 每次
visibilityState === 'hidden'时遍历暂停，'visible'时按需恢复（不是必须全部重启） - 务必在页面卸载前（
beforeunload或pagehide）清空所有定时器，否则可能残留
示例：
const activeTimers = new Set();
const startTimer = (cb, ms) => {
const id = setInterval(cb, ms);
activeTimers.add(id);
return id;
};
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
activeTimers.forEach(clearInterval);
activeTimers.clear();
}
});
哪些定时器该停，哪些可以保留
不是所有 setInterval 都该一刀切暂停。要区分「业务强依赖」和「体验优化型」：
- 轮询接口（如消息未读数）、倒计时（订单支付）、动画帧（
requestAnimationFrame）——建议暂停，避免白跑请求或错失时间点 - 本地日志采样、埋点节流（如每 30s 上报一次曝光）、非关键 UI 动效 —— 可停，节省 CPU 和电量
- 但
setTimeout延迟执行的清理逻辑（如防抖后提交表单）通常不该停，否则用户切回来可能丢失操作 - 注意：Node.js 环境无
document，SSR 渲染时需加typeof document !== 'undefined'守卫
常见错误：visibilitychange 触发时机与竞态问题
最常踩的坑是：在 visibilitychange 回调中又启动新定时器，结果页面刚切回 visible 就触发多次重复逻辑。比如在回调里调 startTimer(fetchData, 5000)，而用户快速切走又切回，会累积多个并发请求。
- 解决方法：用布尔标记（如
isPollingActive）配合状态检查，而不是无条件启动 - 另一个坑：在 React 组件中监听，但没做
useEffect清理，导致卸载后仍触发回调，this或setState报错 - 还有人误以为
visibilityState变化会自动暂停 JS 执行——其实不会，JS 线程照常跑，只是你得自己管定时器
真正容易被忽略的是：Chrome 88+ 对后台标签页的定时器做了节流（setTimeout 最小间隔被拉长到 1s），但这个行为不可控、不跨浏览器，不能当作暂停逻辑的依据。
