全屏切换需防抖，因浏览器（如chrome、safari）触发fullscreenchange事件异常频繁且不稳定，易致状态抖动、重复请求；应使用200–300ms防抖，回调中重读document.fullscreenelement，并与visibilitychange解耦处理。
浏览器全屏切换（如按 F11 或调用 requestFullscreen()）会触发 fullscreenchange 事件，但该事件在部分浏览器（尤其是 Chrome 和 Safari）中存在异常行为：同一操作可能连续触发 2–3 次、中间夹杂 visibilitychange、甚至在退出全屏后短暂闪回“已全屏”状态。若直接响应这些事件更新 UI 或拉取数据，极易导致状态抖动、重复请求或组件错位。
为什么全屏切换需要防抖
全屏状态变化本身是离散动作，但浏览器底层实现不统一，常见异常包括：
- Chrome 中快速按 F11 可能触发两次
fullscreenchange，间隔仅几十毫秒 - Safari 在从全屏退出时，先发一次
fullscreenchange（document.fullscreenElement === null），紧接着又发一次（仍为null），造成重复处理 - 配合标签页切换时，
visibilitychange和fullscreenchange交错触发，若两者都更新同一状态（如“是否处于活跃全屏视图”），就会互相覆盖
用防抖包装 fullscreenchange 回调
核心思路是：忽略中间的瞬时波动，只以用户“稳定进入/退出全屏”后的最终状态为准。推荐使用标准防抖函数，并确保能正确读取当前全屏状态：
- 防抖延迟设为 200–300ms：足够过滤掉浏览器误触发，又不会感知延迟
- 回调内应重新读取
document.fullscreenElement，而非依赖事件对象（因事件对象可能携带过期值） - 避免与
visibilitychange共享同一状态更新逻辑，二者应解耦；可设独立标志位（如isFullScreenStable）供 UI 渲染使用
示例代码：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
const handleFullscreenChange = () => {
const isNowFullscreen = !!document.fullscreenElement;
// 更新你的状态管理器或 React setState
updateUI({ isFullscreen: isNowFullscreen });
};
const debouncedFullscreen = debounce(handleFullscreenChange, 250);
document.addEventListener('fullscreenchange', debouncedFullscreen);
结合 visibilitychange 做协同防抖
当用户 Alt+Tab 切出再切回全屏页面时，visibilitychange 和 fullscreenchange 往往成对出现，但顺序不确定。此时可引入“联合稳定态”判断：
- 定义一个“页面处于有效全屏”的条件：必须同时满足
!document.hidden且!!document.fullscreenElement - 对两个事件分别防抖，但状态更新函数共用同一逻辑；防抖时间保持一致（如都用 250ms），避免因时间差导致状态不一致
- 可加简单节流兜底：若 1 秒内收到超过 3 次相关事件，强制清空定时器并立即执行一次，防止极端情况锁死
排查异常时的关键检查点
遇到全屏状态异常，优先验证以下几项：
- 是否在监听前已存在未清除的
fullscreenchange监听器（尤其 SPA 路由复用组件时） - 是否在
fullscreenerror事件中遗漏了错误日志，某些权限拒绝（如 iframe 无allowfullscreen）会导致静默失败并干扰状态流 - 是否在移动端（iOS Safari）误用了
webkitIsFullScreen等废弃属性——应统一用标准document.fullscreenElement - React/Vue 组件卸载时，是否调用
removeEventListener清理防抖函数？否则闭包中持有的this或组件实例会持续占用内存
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
