结论：必须采用“可视区+缓冲区”动态管理策略，仅渲染当前页及上下各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 移除或复用。

抖音/tiktok直播录制并发布

自动从直播录屏（.webm/.mp4/.mov）识别高光时刻并切割为短视频片段，支持音频能量、场景变化、音画混合、音画并集和ASR关键词五种分析方式，可输出独立片段与合并视频。适用于直播录屏自动剪高光、回放切情绪高点、声音峰值提取精彩片段等任务。

下载

• 用 :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 中修改它
• 无限加载时，videoList push 新数据后，不能直接 this.videoList = [...this.videoList] —— 这会触发整个列表重渲染。应使用 this.$nextTick(() => this.$forceUpdate()) 或更稳妥地用 splice 替换局部片段