uni-app中video组件无法响应滑动全屏，因iOS/安卓WebView中video为原生控件，事件穿透被拦截且不支持z-index；应使用scroll-view容器配合ref定位可视区中心视频并控制播放。
uni-app 中 video 组件无法响应滑动全屏的常见原因
直接在 video 上绑定 @touchstart 或监听 scroll-view 滚动，大概率失效——因为 video 在 iOS（尤其是微信小程序）和部分安卓 WebView 中是原生控件，事件穿透被拦截，且不支持 z-index 层级覆盖。你看到的“滑动”其实是页面滚动，不是视频本身在动。
真正可行的路径是：用 scroll-view 做容器，每个 video 单独占满视口，靠滚动位置切换「当前播放项」，而非让单个 video 跟着手指移动。
- 必须设置
scroll-y="false"+scroll-x="true"（横向滑动）或更常用的是scroll-y="true"（竖向滑动），并开启bounce="false"防止回弹干扰判断 -
video不能设为position: absolute或脱离文档流，否则scroll-view无法正确计算滚动高度 - 真机调试时，iOS 微信环境需额外加
enable-play-gesture="true"才允许手势触发全屏（否则点按无效）
如何用 scroll-view + ref 定位当前播放视频
核心不是“滑动视频”，而是“滑动后识别哪个视频在可视区中心”，再调用它的 play()、pause() 方法。uni-app 的 scroll-view 不提供滚动帧回调，得靠 @scroll 事件 + 节流 + 元素位置计算。
实操建议：
抖音快手短视频创作专家
下载
抖音/快手短视频全栈专家。提供内容策划、脚本撰写、爆款拆解、算法运营、带货策略服务。适用于：创作短视频脚本、制定内容选题、分析爆款视频、制定平台运营策略、撰写带货话术、设计标题封面、理解算法逻辑。服务对象：短视频创作者、自媒体运营、品牌方、MCN机构。
- 给每个
video加:ref="'video' + index"，并在onReady后用this.$refs[`video${index}`][0].getBoundingClientRect()获取位置（注意：H5 和小程序 API 返回字段不同，小程序用uni.createSelectorQuery()更稳） - 在
@scroll回调中，只检查滚动 y 值是否落在当前 video 区域的中间 1/3 范围内，避免频繁切换 - 暂停其他所有 video，只对命中项调用
play()；若离开可视区超 200ms，再pause()（防内存占用） - H5 端可直接用
IntersectionObserver替代手动计算，但小程序不支持，需条件编译
video 全屏逻辑在不同平台的表现差异
uni-app 的 video 组件底层映射到各端原生能力，行为不一致是常态：
- 微信小程序：调用
requestFullScreen()后会进入系统全屏页，返回时触发@fullscreenchange，但无法自定义状态栏/导航栏样式 - App（iOS）：
player-type="landscape"可强制横屏，但需在manifest.json中开启「横屏支持」，否则无效 - H5：无真正全屏，只能用
webkitRequestFullscreen()模拟，且部分安卓浏览器禁止自动全屏（需用户手势触发） - 抖音式体验关键点：全屏时不显示 controls，用自定义按钮控制播放/点赞，且退出全屏后要恢复原 scroll-view 位置（需记录 lastScrollTop）
性能与体验避坑点
大量 video 同时存在会导致内存飙升、滑动卡顿，尤其低端安卓机。这不是代码写得不好，而是原生限制。
- 不要一次性渲染全部视频，用「可视区 + 前后各 1 个」的懒加载策略（类似
virtual-list思路） - 每个
video必须设preload="auto"（小程序）或preload="metadata"（H5），否则首帧加载延迟明显 - 暂停时务必调用
pause()并设src=""（或src="data:,"），否则音频可能后台继续播放 - 安卓部分机型（如华为 EMUI）会强制关闭后台 video 解码，需监听
@error并重置src
最麻烦的其实是「滑动过程中视频突然黑屏或卡住」——这通常是因为 scroll 事件太密导致连续调用 play()，而原生 video 尚未 ready。加个 isPlaying 标志位 + canplay 事件守门，比任何节流都管用。
