customelement不能替代原生全屏触发逻辑，因其无法绕过浏览器对requestfullscreen()的严格限制：必须由可信用户手势触发、目标元素须已挂载且可见、且仅支持特定html元素；自定义元素只能作为容器和控制器，委托内部真实可全屏元素执行。
不能用自定义元素（customElement）直接封装全屏逻辑并“一键全屏”，因为 requestFullscreen() 必须由用户手势触发，且目标元素必须已挂载、可见、非 <iframe></iframe> 内部内容——这些约束无法被自定义元素自动绕过。
为什么 customElement 不能替代原生全屏触发逻辑
自定义元素本质是语法糖，它不改变浏览器对 Fullscreen API 的安全策略。即使你在 connectedCallback 里调用 this.requestFullscreen()，也会因缺少用户手势上下文而静默失败或抛 NotAllowedError。
-
requestFullscreen()只响应 click、keydown（且event.isTrusted === true）等可信事件，不能在生命周期钩子中主动发起 - 自定义元素若在 DOM 尚未挂载时就尝试调用（比如
document.createElement('my-fullscreen')后立刻调用），会因document.body.contains(this) === false失败 - 若自定义元素内部包裹了
<video></video>或<div>，全屏目标仍是那个子元素，而非自定义标签本身——浏览器不识别自定义标签为可全屏的 HTMLElement 实例 <h3>如何让 customElement 正确承载全屏交互</h3> <p>自定义元素可以作为“容器+控制器”，把全屏能力委托给其内部真实可全屏的子元素（如 <code><video></video>、<canvas></canvas>或带id的<div>），自身只负责绑定事件、透传状态、处理样式。 <ul> <li>在 <code>render()或connectedCallback()中确保子元素已存在且可见（避免display: none或visibility: hidden） - 监听自身的
click事件，在回调中调用子元素的requestFullscreen()，而不是调用this.requestFullscreen() - 通过
static get observedAttributes()监听fullscreen属性变化，并在attributeChangedCallback中同步更新 UI（如按钮文字） - 在
disconnectedCallback()中清理document.addEventListener('fullscreenchange', ...)，防止内存泄漏
示例结构：
<my-video-player src="demo.mp4"></my-video-player>，内部渲染为：
<video src="demo.mp4" controls></video><button onclick="this.parentElement.querySelector('video').requestFullscreen()">全屏</button>
常见错误：把 customElement 当成全屏代理
开发者常误以为只要在自定义元素上加 is="my-fullscreen" 或实现 requestFullscreen() 方法就能触发，但浏览器根本不认这个代理行为。
- 写
this.requestFullscreen()→ 报错：TypeError: this.requestFullscreen is not a function（除非你手动挂载，但依然无效） - 在
connectedCallback里调用setTimeout(() => this.querySelector('video').requestFullscreen(), 0)→ 失败，因脱离手势上下文 - 用
shadowRoot封装后调用内部video的requestFullscreen()→ Safari 会拒绝（跨 Shadow DOM 边界不被视为“同一元素”） - 给自定义元素加
allowfullscreen属性 → 无效，该属性只对<iframe></iframe>生效
真正关键的是：全屏入口点必须落在用户可点击的真实 DOM 元素上，customElement 只能组织逻辑、隔离样式、复用结构，不能越权接管浏览器的安全模型。
