最直接的方案就是直接用 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组件，否则手势跟手、后台音频、低延迟都做不到。
实际开发中真正难的不是“怎么切”，而是“什么时候销毁、什么时候预加载、什么时候强制暂停”——边界点稍有偏差，用户划着划着就卡住或黑屏了。这才是需要花精力去打磨的地方。
