uni-app实现类似抖音上下滑动短视频切换

最直接的方案就是直接用 swiper 加上 vertical="true"，但要是以为这就够了，那可能会踩坑：真机上卡顿、黑屏、自动播放失败，这些问题90%都是因为没处理好 video 实例的生命周期和平台行为差异。

为什么 swiper @change 不能直接用来触发 play()

很多人以为滑动时 @change 会实时触发，其实不然。它不是滚动中的回调，而是分页对齐完成后的信号——也就是滑动还没停稳，DOM 可能都没渲染完呢。在 iOS 上 current 的更新还有微小延迟，依赖它来计算进度或同步动画，大概率会错位。

• 所有播放/暂停的逻辑必须放在 @change 回调内，而不是 @touchmove 或 @transition。
• 在 onSwiperChange 中记得包一层 this.$nextTick，否则 this.$refs.video 可能为 undefined。
• 视频列表动态追加后，要手动重置 currentIndex，否则很容易越界或卡死在空白页面。

video 标签怎么写才能跨端自动播放

iOS Safari 和微信 WebView 对带声音的视频自动播放有硬性限制：没有用户手势前，autoplay="true" 加上 muted="false" 必然失败，表现就是“有声无画”或直接黑屏。

• 首屏视频必须设置 :muted="true" + :autoplay="true"，这样画面才能先出来。
• 监听 @loadedmetadata 或 @canplay，然后调用 videoContext.mute(false) 来尝试开声（部分机型仍然需要用户点一下）。
• H5 端必须加上 playsinline、webkit-playsinline、x5-playsinline，否则 iOS 微信会强制全屏。
• 小程序端要禁用 autoplay，等 @loadedmetadata 触发后再执行 play()，避免并发加载阻塞主线程。

怎么避免内存爆炸和滑动卡顿

如果一次性把100条视频都塞进 swiper-item，完全等同于把整个视频列表一次性全部塞进去。这在浏览器里等于同时解码100个视频的首帧——iOS Safari直接卡死，小程序白屏，App端内存飙升到500MB以上。

• 只保留 current - 1、current、current + 1 这三个 video 实例，其余的用 v-if="false" 彻底移除 DOM。
• 每个 video 设置 preload="metadata"，而不是 "auto"；首次进入可视区才调用 .load()。
• 滑出视口 500ms 后，执行 pause() + src = '' + load() 来释放解码资源。
• 在小程序里，不要用 scroll-view 包裹 video，它会把原生手势截断；改用普通 view + transform: translateY 来模拟滚动。

小程序里 touchmove 为什么监听不到？

微信小程序的 video 是原生组件，层级高于所有 webview 内容，touchstart/move 事件根本无法穿透上去——说真的，这不能怪微信，它就这么设计的。

• 现象：手指一碰到视频区域，touchmove 就不触发，或者只在边框空白处生效。
• 解法：用 cover-view 盖一层透明遮罩，把滑动事件抢过来，再手动控制 video 的显隐与 src 切换。
• 抖音小程序必须用 ref + this.$refs.video.play()，不能用 uni.createVideoContext。
• App 端必须用 nvue + 原生 video 组件，否则手势跟手、后台音频、低延迟都做不到。

实际开发中真正难的不是“怎么切”，而是“什么时候销毁、什么时候预加载、什么时候强制暂停”——边界点稍有偏差，用户划着划着就卡住或黑屏了。这才是需要花精力去打磨的地方。