全屏切换需解决真实问题而非炫技，调用requestFullscreen必须由用户click触发、目标元素可见且非body/documentElement，状态判断唯一依据是document.fullscreenElement，退出须显式调用document.exitFullscreen()并捕获错误，样式适配应针对具体容器并兼顾多浏览器前缀与dvh单位。
管理系统里加全屏切换，不是为了炫技，而是解决真实问题：比如看报表时想屏蔽侧边栏干扰、演示大屏时需要最大化图表区域、或操作表单时临时腾出更多垂直空间。直接套用通用全屏方案大概率翻车——管理系统的 DOM 结构复杂、常含 iframe、有权限控制逻辑，还可能跑在内网低版本浏览器里。
requestFullscreen 调用失败的三个高频原因
点了按钮没反应？大概率卡在这三处：
-
requestFullscreen()没被用户 click 触发：用setTimeout包一层、在fetch().then里调用、或页面load后自动执行，都会被浏览器静默拒绝（不报错，也不进全屏） - 目标元素不可见或未挂载：检查
el.offsetParent !== null，禁用display: none或visibility: hidden；若目标是<iframe></iframe>，必须加allow="fullscreen"属性 - 对
document.body或document.documentElement调用：Safari 会直接拒绝，应选具体容器，例如<main id="content"></main>或你实际要放大的业务模块根节点
状态判断只认 document.fullscreenElement
别自己维护 isFullscreen 变量，也别信 document.isFullscreen（根本不存在）。唯一可信依据就是 document.fullscreenElement：
- 值为
null→ 未全屏（注意是null，不是undefined或false） - 值为某个 DOM 元素 → 当前该元素处于全屏（比如
document.getElementById('content')） - UI 切换文案/图标，必须读取这个值比对，例如：
document.fullscreenElement === contentEl
Safari 的 fullscreenchange 事件触发稍滞后，读状态前可加 Promise.resolve().then(() => ...) 做微任务延迟。
立即学习“前端免费学习笔记（深入）”；
退出全屏必须显式调用 document.exitFullscreen()
只靠用户按 Esc 键退出，你的 JS 逻辑完全无感知，UI 状态立刻脱节。必须主动调用并捕获错误：
- 无需提前判空：现代浏览器中
document.exitFullscreen()在非全屏状态下执行不会中断脚本 - 但老版 Edge 可能抛
NotFoundError，统一加.catch(() => {})避免未处理 promise rejection - 监听
fullscreenchange事件必须绑在document上，不能绑在触发按钮或容器上
:fullscreen 伪类样式适配要点
全屏后布局错乱？常见于管理系统的复杂嵌套结构：
- 不要写
body:fullscreen—— 实际被全屏的是你调用requestFullscreen()的那个元素，比如#content:fullscreen - 移动端 Safari 对
100vh有缩放 bug，推荐用min-height: 100dvh（现代浏览器），回退到100vh - 全屏时隐藏滚动条、重置 margin/padding、撑满视口：
#content:fullscreen { width: 100vw; height: 100dvh; margin: 0; overflow: hidden; } - 兼容旧版：并列写
#content:-webkit-full-screen、#content:-moz-full-screen、#content:-ms-fullscreen
真正容易被忽略的点是：全屏 API 是全局状态，但管理系统往往有多个模块共存，一旦某个模块调用了 requestFullscreen()，其他模块的监听器也会收到 fullscreenchange 事件——别忘了在组件卸载时移除监听，否则可能引发内存泄漏或状态错乱。
