必须由用户手势触发requestfullscreen()，且仅对已挂载的dom元素调用；监听fullscreenchange事件需绑定document并检查document.fullscreenelement；退出全屏须调用document.exitfullscreen()并处理promise。
怎么用 requestFullscreen() 触发全屏
浏览器原生全屏不是靠 CSS 撑起来的，必须调用元素的 requestFullscreen() 方法。它只能由用户手势（比如 click、keydown）触发，不能在页面加载或定时器里直接调用，否则会被浏览器静默拒绝。
常见错误现象：Failed to execute 'requestFullscreen' on 'Element': API can only be initiated by a user gesture.
- 只对一个 DOM 元素调用，通常是
<div id="viewer"> 或 <code><video></video>这类容器 - 必须确保该元素已挂载到文档中（
document.body.contains(el)为 true），否则报错 - 移动端 Safari 对
<iframe></iframe>内内容限制更严，需加allow="fullscreen"属性 - 不要写成
document.requestFullscreen()—— 那是让整个页面全屏，但实际兼容性差，且现代浏览器基本不支持 - 必须用
document.addEventListener('fullscreenchange', handler)，别绑在触发元素上 - 判断是否真进入全屏，要查
document.fullscreenElement（注意拼写是fullscreen，不是fullScreen或FullScreen） - 退出全屏时
document.fullscreenElement为null，别误判为undefined - Chrome 和 Firefox 支持良好，但旧版 Safari 用的是
webkitfullscreenchange和document.webkitFullscreenElement，建议加兼容层 - 写法必须是
video:fullscreen或#player:fullscreen，不能漏掉冒号前的元素选择器 - 不要依赖
*:fullscreen—— 太宽泛，且部分浏览器不识别 - 全屏状态下浏览器会重置部分默认样式（比如
margin、background），建议显式重设body或容器的margin: 0和width/height: 100vh - 若用
transform: scale()或position: fixed做自定义全屏，本质不是真正全屏，无法响应fullscreenchange事件 - 正确写法是
document.exitFullscreen()，不是el.exitFullscreen() - 调用前最好先检查
document.fullscreenElement是否存在，避免无意义调用导致 rejected Promise - 如果之前是用
el.requestFullscreen()进入全屏，退出时不需要指定元素，浏览器自动知道退哪个 - 某些安卓 WebView 中，
exitFullscreen()可能不触发fullscreenchange事件，建议加 timeout fallback 或轮询document.fullscreenElement
为什么 fullscreenchange 事件监听不到
全屏状态变化是异步的，而且事件名大小写敏感：标准是 fullscreenchange，不是 fullscreenChange 或 onfullscreenchange。监听对象也不是 document 就完事，得看谁发起的全屏 —— 但状态变化统一在 document 上抛出。
全屏后样式错乱？:fullscreen 伪类怎么写才生效
CSS 的 :fullscreen 是作用于当前全屏元素本身的，不是它的子元素。而且它不支持链式写法（比如 .container:fullscreen .content 在某些浏览器里会失效），优先用直接作用于全屏元素的规则。
退出全屏失败？exitFullscreen() 的调用位置很关键
exitFullscreen() 只能从 document 调用，不是从某个元素调用。而且它返回 Promise，但多数场景下你得等它 resolve 才能安全执行后续逻辑（比如恢复按钮状态）。
真正麻烦的不是调用 API，而是不同浏览器对“谁算用户手势”的认定差异 —— 比如在 setTimeout 里包装 click 事件，或者从自定义事件转发过来的 click，在 Safari 上大概率被判定为非可信事件。这点很容易被忽略，直到 QA 提出“点按钮没反应”才回头查。
