结论：swiper+video是当前最可控、兼容性最好、上线风险最低的竖屏刷视频方案；追求高性能或弹幕/倍速需接入腾讯视频插件（但须企业主体、开放类目、appid严格匹配）。
直接上结论：用 swiper + video 组合实现竖屏刷视频是当前最可控、兼容性最好、上线风险最低的方案；想追求更高性能或弹幕/倍速等能力，必须接入腾讯视频插件（但企业主体+类目审核缺一不可）。
swiper 垂直滚动 + video 自动播放怎么配才不卡
微信小程序对 video 组件有明确限制：同一时间最多 10 个活跃实例，超出会触发销毁逻辑甚至白屏。而刷短视频页面往往要预加载前后 2–3 个视频，必须手动控制生命周期。
- 用
swiper的vertical="true"和circular="true"实现无缝上下滑动，duration设为 300–500ms，避免过快导致视觉割裂 -
video必须加autoplay="false"，靠@change事件监听当前 swiper-item 索引，只对current对应的video调用this.$nextTick(() => ctx.play()) - 离开可视区域的
video要主动ctx.pause()，并清空src（设为空字符串），否则内存持续上涨，低端机 5–6 个视频后就明显卡顿 - 不要在
swiper-item里嵌套scroll-view或movable-view，会导致video渲染异常或静音
腾讯视频插件接入失败的三个硬性门槛
很多开发者卡在“添加插件成功但运行报错”，不是代码问题，而是权限链没走通。
- 小程序主体必须是企业，个人/个体户/事业单位均不可用 —— 微信后台“设置 > 基本信息”里看“主体类型”
- 小程序类目必须属于开放范围，如“工具-视频工具”“社交-内容社区”“教育-在线教育”等，非开放类目（如“电商-综合电商”）即使加了插件也无法调用
-
manifest.json中的mp-weixin.appid必须和微信公众平台中该插件绑定的小程序完全一致，且插件状态为“已通过审核”（后台“第三方服务 > 插件管理”里确认）
video 组件在真机和开发者工具表现不一致怎么办
微信开发者工具对 video 的模拟非常粗糙：自动播放策略、静音逻辑、全屏行为、资源释放时机都和真机不同，仅可作结构验证。
- 所有播放逻辑（尤其是
play()/pause()调用时机、bindended是否触发、binderror错误码）必须在 iOS/Android 真机上测试 - H5 端若需兼容，不能直接复用
video属性，要用#ifdef H5包裹独立逻辑，例如 H5 不支持enable-danmu，也无danmu-list接口 - 遇到“点击无反应”“播放一半黑屏”，先检查真机是否开启“后台音频播放”权限（iOS 设置 > 微信 > 后台App刷新；安卓各厂商路径不一，需引导用户手动打开）
为什么不能用 live-player 替代 video 刷短视频
live-player 是为直播流（RTMP/FLV/HLS）设计的原生组件，用它播点播 MP4 会引发一系列隐性问题。
- 不支持
controls属性，无法显示原生进度条/音量控件，所有 UI 都得自己用cover-view手写，开发成本翻倍 - 没有
bindtimeupdate，无法做精准进度同步或弹幕时间轴渲染 - 退出全屏后，部分安卓机型会残留黑屏层，必须手动调用
exitFullScreen()并延时重置src - 微信明确不建议将
live-player用于点播场景，审核时可能被驳回（尤其当页面标题含“短视频”“刷视频”等关键词）
真正麻烦的从来不是写几行 swiper 或配个插件 ID，而是每个环节都卡在微信生态的权限墙和真机行为差异上——调试时多看真机日志里的 VMxxxx:xx 错误码，比反复改代码更有效。
