必须由用户手势(如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。











