结论：必须采用“可视区+缓冲区”动态管理策略，仅渲染当前页及上下各2个item，配合preload="none"、用户手势后播放、@transition监听等优化，否则iOS H5必卡顿、内存溢出、自动播放失效。
直接说结论：用 swiper 做抖音式竖向视频滑动，必须放弃“全量渲染”，改用“可视区+缓冲区”动态管理策略；否则 iOS H5 上必卡、必内存溢出、必自动播放失效。
为什么 swiper + v-for 全量渲染一定会崩
这不是配置问题，是 DOM 与视频资源的双重压力叠加：
-
swiper-item每多一个，就多一个video标签 —— 即使display: none或不在可视区，iOS Safari 仍会尝试解码首帧、加载元数据 - H5 端
swiper底层用的是transform: translateY+transition，但当 DOM 节点超 30 个，主线程 layout 计算时间 >16ms，滑动立刻掉帧 - uni-app 的
current响应式更新在快速滑动时频繁触发@change，若你在里面做this.currentIndex = e.detail.current+ 触发数据重载，等于主动制造“事件雪崩”
怎么用 swiper 实现真正可用的无限滑动
核心是“只保 5 个 item”：当前页 + 上下各 2 个缓冲项。其余全部从 DOM 移除或复用。
- 用
:current控制高亮项，但v-for不遍历全部数据，只遍历videoList.slice(currentIndex - 2, currentIndex + 3) - 每个
video必须加preload="none"，且首次进入可视区才调用.load()和.play() - 监听
@transition（不是@change）来判断滑动是否结束，再触发下一批数据预加载或清理旧节点 - 给每个
video绑定id并缓存HTMLVideoElement实例，避免重复获取：const video = uni.createSelectorQuery().in(this).select(`#video-${id}`).exec()
video 自动播放失败的硬解法（尤其 iOS H5）
iOS Safari 对自动播放限制极严：必须用户手势触发、不能静音、不能后台播放。抖音式体验绕不开这点，只能妥协+补救：
- 首次进入页面时，不自动播放任何视频，等用户手指触发一次
touchstart后，再允许后续video.play() - 所有
video标签必须带muted和autoplay属性，但实际调用.play()必须在用户交互后（如onTouchStart回调里） - 不要依赖
@canplay或@loadeddata立即播放 —— iOS 下这些事件可能永远不触发，改用setTimeout(() => video.play(), 100)配合try/catch捕获NotAllowedError - 播放失败时，显示“点击播放”浮层，而不是黑屏死等
容易被忽略的三个致命细节
很多团队卡在最后 10% 的体验上，往往是因为这几个点没处理：
-
swiper的:vertical="true"在 H5 端必须配合height: 100vh，但某些安卓 WebView 会把地址栏高度算进vh，导致底部留白 —— 改用height: calc(100vh - env(safe-area-inset-bottom)) - 滑动过程中快速切换
current值，会导致 swiper 内部动画状态错乱，表现为“跳帧”或“回弹”。正确做法是：只在@transition结束后才更新currentIndex，且禁止在@change中修改它 - 无限加载时，
videoListpush 新数据后，不能直接this.videoList = [...this.videoList]—— 这会触发整个列表重渲染。应使用this.$nextTick(() => this.$forceUpdate())或更稳妥地用splice替换局部片段
