uni-app视频流上下滑动需分平台实现：小程序用cover-view遮罩劫持touch事件控制video显隐切换，App端必须用nvue原生video组件并手动管理3个实例的生命周期，H5仅可凑合。
uni-app
中用
组件实现上下滑动视频流，核心是「原生渲染 + 手势劫持 + 懒加载」
直接说结论：uni-app 默认的
在非 App 平台（尤其是微信小程序）无法真正全屏、无法拦截滑动手势、无法稳定复用——必须分平台处理，App 端走
渲染，小程序端靠
组合 +
手动控制播放器显隐与切换。
为什么
在小程序里不能直接上下滑？
微信小程序的
是原生组件，层级高于所有 webview 内容，
事件根本无法穿透到它上面；同时，
在
上无效，你监听不到手指在视频区域的滑动。结果就是：用户想上滑切视频，手指一碰到视频就“失灵”了。
现象：
在
区域不触发，或只在边框空白处生效
原因：小程序原生组件的事件隔离机制，不是 bug，是设计
解法：用
盖一层透明遮罩，把滑动事件抢过来，再手动控制
的
、
和
App 端必须用
+
原生组件
H5 和小程序能“凑合”，但 App 端要流畅、低延迟、支持后台音频、手势跟手，就必须放弃
页面，改用
。uni-app 的
视频组件（
）是真原生，支持
、
、
，且可被
事件完整捕获。
jQuery仿抖音视频功能
jQuery仿抖音视频功能.
下载
记录
计算偏移量，当
时立即触发切换
切换前调用
，切换后
关键配置：
、
、
，否则 UI 干扰手势
如何避免内存爆炸和卡顿？
抖音
式视频流最常踩的坑不是“怎么切”，而是“切多了崩”。100 条视频全挂
标签？小程序直接白屏，App 端内存飙升到 500MB+。
只保留当前页 + 上一页 + 下一页共 3 个
实例，其余
或
销毁
切换完成 500ms 后，对已滑出视口的
调用
+
+
释放资源
小程序中慎用
：设为
，等
触发后再
，否则大量视频并发加载会阻塞主线程
App 端用
时，
的
设为
即可，系统会自动管理缓冲区
真正难的不是滑动逻辑，而是「什么时候销毁、什么时候预加载、什么时候强制暂停」——这些边界点稍有偏差，用户划着划着就卡住或黑屏了。
videovideonativecover-view + videobindtouchmovevideovideotouchstart/movebind:touchmovevideotouchmovevideocover-viewvideosrcautoplayshow-center-play-btnnvuevideovuenvuenvueplaybackRatedirectiongestureConfigtouchtouchstarttouches[0].pageYtouchmoveMath.abs(deltaY) > 50this.$refs.video.pause()this.$refs.nextVideo.play()show-progress="false"show-fullscreen-btn="false"show-center-play-btn="false"videovideov-if="false"removeChildvideopause()src = ''load()autoplayfalsebindloadedmetadataplay()nvuevideopreload"auto"