html pip 不改善小窗体验，反而干扰自定义小窗逻辑；因其脱离dom、不可控样式/位置/内容，且ios/webview兼容性差，应优先采用自定义方案。
HTML 画中画（Picture-in-Picture, PiP）本身不改善小窗播放体验，反而可能干扰或覆盖已有小窗逻辑 —— 尤其当你的应用已自行实现悬浮窗、MiniPlayer 或 WebView 内嵌小窗时。
为什么 document.pictureInPictureElement 和 requestPictureInPicture() 在小窗场景下容易冲突
浏览器原生 PiP 是全屏窗口级的独立视图，它会接管视频元素并脱离当前页面 DOM 树。如果你的小窗是通过 CSS transform + fixed 定位 + z-index 模拟的「伪小窗」，调用 requestPictureInPicture() 后：
• 视频会从你的小窗容器中消失，跳转到系统级 PiP 窗口（通常右下角，不可拖动位置）
• 原小窗区域只剩空白或 fallback 内容
• pictureinpicturechange 事件无法控制样式、尺寸或关闭逻辑
• iOS Safari 完全不支持 requestPictureInPicture()，仅支持系统手势唤起（如双指长按），行为不可控
哪些小窗场景不该用 HTML PiP
以下情况直接禁用 requestPictureInPicture()，改用自定义方案更可靠：
• 小窗需支持拖拽、缩放、双击放大/还原、与主界面联动（如点击小窗跳回详情页）
• 小窗内含非视频内容（如弹幕、进度条、操作按钮），而原生 PiP 只渲染 <video></video> 元素本身
• 应用运行在 WebView（如微信、抖音内嵌页），多数 Android WebView 不支持 PiP API，或需手动开启 setMediaPlaybackRequiresUserGesture(false) 等配置
• 需兼容 iOS 微信（WKWebView 禁用 PiP API，调用会静默失败，无错误提示）
真要用 PiP，必须绕开的三个坑
如果明确需要系统级 PiP（比如适配桌面 Chrome 的多任务场景），务必注意：
• requestPictureInPicture() 必须由用户手势触发（click/tap），不能在 autoplay 后自动调用，否则抛出 NotAllowedError
• 视频必须满足 playsInline + webkit-playsinline + controls（iOS 要求），否则 iOS 上无法唤起 PiP
• 监听 leavepictureinpicture 事件时，不要假设视频会自动回到原 DOM 位置 —— 它只是重新挂载，但 currentTime、playbackRate 等状态可能丢失，需手动同步
真正影响小窗体验的是容器层级、播放状态同步、输入事件穿透和内存管理，不是是否启用了 PiP。别让一个系统 API 带偏了核心交互设计。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
