requestpictureinpicture()不能当可控小窗用，因其脱离dom、无法自定义样式/交互且ios/webview兼容性差；真需小窗须用挂载body的fixed定位dom方案实现。

HTML 画中画（requestPictureInPicture()）本身不是小窗播放方案，它只是把 <video></video> 弹出到系统级悬浮窗口——你无法控制尺寸、位置、内容、是否可拖动，也不支持非视频元素。真要实现可控小窗，必须放弃依赖 PiP，改用自定义 DOM 实现。

为什么 requestPictureInPicture() 不能当小窗用

浏览器调用后，视频会彻底脱离当前页面 DOM 树，进入操作系统管理的独立窗口；你的 CSS、JS、事件监听全部失效。常见误判场景：

• 以为加了 z-index 和 position: fixed 就是“小窗”，结果一调 requestPictureInPicture()，小窗直接消失，只剩一个系统 PiP 窗口在右下角不动
• 在 iOS Safari 上硬写 video.requestPictureInPicture()，静默失败——iOS 只响应双指长按手势，且不暴露 JS 接口
• 小窗里需要显示弹幕、进度条、分享按钮，但原生 PiP 只渲染 <video></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 事件做清理工作：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 隐藏自定义小窗 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 监听），这才是真实需求。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！