requestPictureInPicture()不能当可控小窗用，因其脱离DOM、无法自定义样式/交互且iOS/WebView兼容性差；真需小窗须用挂载body的fixed定位DOM方案实现。
HTML 画中画（requestPictureInPicture()）本身不是小窗播放方案，它只是把 <video> 弹出到系统级悬浮窗口——你无法控制尺寸、位置、内容、是否可拖动，也不支持非视频元素。真要实现可控小窗，必须放弃依赖 PiP，改用自定义 DOM 实现。
为什么 requestPictureInPicture() 不能当小窗用
浏览器调用后，视频会彻底脱离当前页面 DOM 树，进入操作系统管理的独立窗口；你的 CSS、JS、事件监听全部失效。常见误判场景：
- 以为加了
z-index和position: fixed就是“小窗”，结果一调requestPictureInPicture()，小窗直接消失，只剩一个系统 PiP 窗口在右下角不动 - 在 iOS Safari 上硬写
video.requestPictureInPicture()，静默失败——iOS 只响应双指长按手势，且不暴露 JS 接口 - 小窗里需要显示弹幕、进度条、分享按钮，但原生 PiP 只渲染
<video>自身，其他 DOM 全被丢弃 - 父容器用了
overflow: hidden或transform，导致 PiP 触发前就判定 video 不可见，调用直接被忽略
自定义小窗的关键 DOM 与样式约束
真正可控的小窗本质是「固定定位 + 层级穿透 + 状态同步」，不是靠浏览器 API。核心要点：
- 小窗容器必须挂载在
document.body下，避免被任意父级overflow: hidden、transform、clip-path截断 - 必须设置
pointer-events: auto（默认是auto，但若父级设了none会继承），否则拖拽、点击按钮全失灵 - 使用
transform: scale()配合transition实现缩放动画，别用width/height直接改——后者触发重排，卡顿明显 - 双击放大/还原需监听
dblclick，并手动切换 class 控制 transform 和 z-index，不能指望 PiP 事件 - 主视频暂停时，小窗内视频也要同步
pause()；主界面跳转时，小窗要保留状态并可点击返回——这些都得自己写逻辑
哪些场景下 PiP 还值得保留
PiP 不是废功能，而是备用通道：当用户主动点击系统 PiP 图标（如 Chrome 地址栏媒体控件里的两个重叠矩形），或在支持设备上双指长按时，你可以监听 enterpictureinpicture 事件做清理工作：
立即学习“前端免费学习笔记（深入）”；
- 隐藏自定义小窗 DOM，避免视觉冲突
- 暂停主界面视频的自动播放逻辑（防止 PiP 和主视频同时播）
- 记录当前播放时间点，等用户退出 PiP 后恢复
- 在
leavepictureinpicture回调里重新 show 自定义小窗，并 seek 到上次位置
注意：document.pictureInPictureElement 是唯一可靠的判断依据，别用 video.readyState 或 video.paused 猜测状态。
移动端和 WebView 的现实限制
如果你的应用跑在微信 WebView、QQ 浏览器、或某些安卓定制浏览器里，PiP 基本不可用：
- Android WebView 默认禁用 PiP，需 App 侧显式开启
WebSettings.setMediaPlaybackRequiresUserGesture(false)，但多数宿主 App 不开放该配置 - iOS WKWebView 完全不支持
requestPictureInPicture()，连document.pictureInPictureEnabled都是false - 华为、小米等厂商浏览器对 PiP 入口藏得极深，用户根本找不到，更别说主动触发
这时候坚持用 PiP，等于把交互链路交给不可控因素。自定义小窗虽然多写几十行 JS，但所有行为都在你手里——包括退后台后是否保持显示（靠 visibilitychange + pagehide 监听），这才是真实需求。
