visibilitychange事件未触发主因是监听注册过晚或位置错误，需在domcontentloaded前注册；document.hidden初始值可能为true，不可依赖；需同时清理requestanimationframe并手动恢复audiocontext。
页面切后台时 visibilitychange 事件没触发？检查 document.hidden 和监听位置
多数情况不是事件失效，而是监听加晚了或加错了地方。页面加载完成前注册监听，否则可能错过初始状态（比如从后台恢复时页面已激活，visibilitychange 不会回补）。document.hidden 是实时只读属性，但它的值在页面初始化阶段就已确定——如果脚本异步执行（如放在 setTimeout 或模块懒加载里），很可能读到的是 true 却以为是“正常状态”。
- 监听必须在
DOMContentLoaded之前或之中注册，推荐直接写在<script></script>标签最顶部 - 不要依赖首次进入页面时的
document.hidden值做业务判断，它可能是true（例如从 PWA 后台冷启动） - 移动端某些 WebView（如微信 iOS 8.0.32）对
visibilitychange支持不完整，需 fallback 到pagehide/pageshow
暂停定时器和音视频时，别只停 setTimeout，漏掉 requestAnimationFrame
visibilitychange 最常被用来暂停轮询、动画、音频播放等资源消耗行为，但很多人只清 setTimeout/setInterval，却忘了 requestAnimationFrame 仍在后台疯狂调用——它不会因页面不可见而自动节流，在 iOS Safari 中甚至持续执行，导致电量飙升。
- 每次
requestAnimationFrame调用都要存 ID，并在visibilitychange触发且document.hidden === true时用cancelAnimationFrame清除 - 恢复时不能简单重开动画循环，要重新调用
requestAnimationFrame启动，否则可能丢失一帧或错位 - Web Audio API 的
AudioContext在页面隐藏时会被系统 suspend，恢复后需手动调用resume()，否则音频静音
Chrome 117+ 和 Safari 17 对 visibilitychange 的触发时机变了
新版浏览器更严格区分“视觉可见”和“系统焦点”。比如 Chrome 117+ 中，弹出全屏 dialog 或打开 DevTools 时，document.hidden 仍为 false，但页面实际已失去用户注意力；Safari 17 则在标签页被其他窗口完全遮挡时才触发 visibilitychange，而非仅切到其他标签页。
- 不要假设
visibilitychange能覆盖所有“用户离开”场景，对关键逻辑（如保活心跳、锁屏检测）应组合使用blur、focus、pagehide事件 -
document.visibilityState的值现在更细：除了visible和hidden，还可能出现prerender（已废弃）或unloaded（极少见），判断时建议用=== 'visible'而非!== 'hidden' - 测试时别只切标签页，要真关掉窗口、切桌面、锁屏，才能覆盖全链路
后台恢复后音频/视频自动播放失败？不是事件问题，是 Autoplay 策略拦截
很多开发者以为 visibilitychange 恢复后直接 play() 就行，结果报错 DOMException: play() failed because the user didn't interact with the document first。这是浏览器 Autoplay 策略在起作用——即使页面“回来”了，只要没发生过用户手势（click/tap/key），媒体无法自动播放。
立即学习“前端免费学习笔记（深入）”；
- 不能靠
visibilitychange触发play()，必须等待一次显式用户交互（哪怕是个透明按钮 click）后再恢复媒体 - 可提前在
visibilitychange回调中调用audio.play().catch(e => console.log('deferred'))，但要准备好被拒绝，然后在下一次用户操作时重试 - 若用
video标签，加上muted属性能绕过大部分限制；但带声音的AudioContext仍需用户手势激活
