必须由用户手势（如click）触发element.requestfullscreen()，不可在定时器或非直接事件中调用；退出全屏统一用document.exitfullscreen()并try-catch；监听fullscreenchange和fullscreenError事件需绑定到document；移动端支持有限，ios仅允许video等特定元素全屏。
怎么用 requestFullscreen() 触发全屏
浏览器原生全屏必须由用户手势（如 click、tap）触发，不能在页面加载或定时器里直接调用，否则静默失败。现代浏览器都支持 Element.requestFullscreen()，但各浏览器前缀已基本淘汰，不用再写 webkitRequestFullscreen 或 mozRequestFullScreen。
常见错误现象：requestFullscreen() 调用后无反应，控制台也不报错——大概率是触发时机不对，比如在 setTimeout 里执行，或响应了非直接用户事件（如 input 事件后自动调用）。
- 只对「可全屏元素」有效：通常用
、或某个<div>，但 iframe 默认被禁止（需加 <code>allowfullscreen属性） - 调用前建议先检查兼容性：
if (element.requestFullscreen)，避免低版本 safari 报错 - 成功后会触发
fullscreenchange事件，可用它更新按钮文案（如“退出全屏”） - 安全做法：统一用
document.exitFullscreen()，并包裹在try...catch中 - 判断是否处于全屏状态，看
document.fullscreenElement是否为NULL（注意不是fullscreenEnabled，后者只是能力开关） - 移动端 Safari 对全屏支持有限：iOS 15+ 才允许部分元素全屏，且不支持
<video></video>外的元素真正覆盖系统 ui - 务必用
document.addEventListener('fullscreenchange', handler)，不要绑在按钮或容器上 -
fullscreenerror不会冒泡，也不能被preventDefault()，只能靠它定位问题（例如控制台打印document.fullscreenElement看是不是null） - 注意事件触发顺序：先
fullscreenchange，再（可能）跟一个fullscreenerror；但 error 不一定出现，别假设它必达 - 基础写法：
div:fullscreen { width: 100vw; height: 100vh; }，但注意vh在移动端可能不准，建议优先用100%配合position: fixed - 隐藏浏览器地址栏（仅部分 android 浏览器）：需配合
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimal-ui">，但现代 chrome 已弃用minimal-ui - 退出全屏后，记得重置
transform、z-index等可能被全屏过程临时覆盖的样式，否则布局错乱
为什么 document.exitFullscreen() 有时不生效
退出全屏不是针对某个元素，而是全局操作，必须用 document.exitFullscreen()，而不是某个元素的方法。如果当前没处于全屏状态却调用它，多数浏览器不会报错，但也不会做任何事；少数（如旧版 firefox）会抛 NotFoundError 异常。
容易踩的坑：exitFullscreen() 被封装成工具函数后，未加 try-catch，导致后续 js 执行中断；或者误以为要传入之前全屏的元素，写成 el.exitFullscreen() —— 这个方法根本不存在。
立即学习“前端免费学习笔记（深入）”；
fullscreenchange 和 fullscreenerror 怎么监听才可靠
这两个事件绑定在 document 上，不是目标元素。监听位置错了，就收不到回调。尤其 fullscreenerror 很关键——用户拒绝权限、元素被移出 dom、或跨域 iframe 尝试全屏时都会触发它，但默认不报错，容易被忽略。
使用场景：按钮点击后想反馈状态，或需要清理全屏时启动的定时器、画布动画等。
CSS 里怎么写全屏专用样式
全屏状态下，浏览器会给全屏元素自动加上 :fullscreen 伪类（注意不是 :full-screen），同时它的父级和祖先元素会失去部分样式继承。最常被忽略的是滚动条消失、overflow 行为变化，以及字体缩放异常。
性能影响：全屏时若页面含大量 canvas 或 video，某些安卓 webview 会降频渲染，导致卡顿；提前用 @media (display-mode: fullscreen) 做轻量化适配更稳妥。
全屏 API 表面简单，实际绕不开权限模型、移动端限制和事件生命周期。最易被忽略的是：iOS 上无法通过 JS 触发整个网页全屏，只能让视频或 canvas 全屏；而 Android 各厂商 WebView 实现差异极大，真要稳定，得留好降级方案——比如用 scale(1.5) 模拟视觉放大，而非强依赖 API。