原生 loop 属性无法实现真正无缝衔接，50–200ms 黑屏或卡顿是浏览器规范行为；必须用 javascript 主动干预播放时机，通过 ontimeupdate 提前跳转、防抖控制、首尾帧对齐、faststart 优化、优先 webm、强制 playsinline 及确保 readystate=4 等综合手段消除间隙。
原生 loop 属性无法实现真正无缝衔接，50–200ms 的黑屏或卡顿是浏览器规范行为，不是 bug；要消除间隙，必须用 JavaScript 主动干预播放时机。
为什么 loop 属性总会卡一下
浏览器的 loop 只是告诉媒体引擎“播完跳回 0”，但不控制解码缓冲、音频队列清空、帧定位等底层流程。实际表现就是：画面一闪黑、声音断一拍、UI 动效跳变。
-
loop是声明式逻辑控制，不是流衔接机制 - MP4 容器若未带
faststart，首帧加载延迟会放大卡顿感 - iOS Safari 对
loop支持最弱，哪怕写了muted和autoplay，也可能在后台 tab 或低电量模式下失效
用 ontimeupdate 提前跳转比等 ended 更稳
监听播放进度，在到达末尾前 50ms 就把 currentTime 设为 0，能避开自然结束时的解码重置开销。
- 不要等
video.currentTime === video.duration，这时已经晚了 - 推荐阈值设为
video.duration - 0.05，太小（如 0.01）易因精度误差漏判，太大（如 0.2）会提前跳造成画面重复 - 必须加防抖：设个
isJumping标志位，跳转后 100ms 内忽略后续判断，否则可能连续触发多次currentTime = 0 -
video.play()必须调用，且要.catch(() => {})，否则 iOS/Chrome 在非用户手势上下文中会拒绝并抛错
const video = document.querySelector('video');
let isJumping = false;
video.ontimeupdate = () => {
if (isJumping) return;
if (video.currentTime >= video.duration - 0.05) {
isJumping = true;
video.currentTime = 0;
video.play().catch(() => {});
setTimeout(() => { isJumping = false; }, 100);
}
};
首尾帧对齐和编码优化不能省
即使 JS 跳转再快，如果视频末帧是黑场、字幕、或与首帧内容不匹配，人眼照样能感知“跳”。
- 导出时让最后 0.5 秒淡出并冻结在首帧画面上（Premiere / DaVinci 都支持）
- 用 FFmpeg 加
faststart：运行ffmpeg -i input.mp4 -c:v libx264 -c:a aac -movflags +faststart output.mp4 - 优先提供
webm格式：<source src="bg.webm" type="video/webm"></source>，解码更快、体积更小，对低端设备更友好 - 避免用 HEVC 编码的 MP4 做背景视频——iOS 部分机型不支持硬件解码，会导致循环卡顿加剧
iOS 上 playsinline 不是可选项，是硬性前提
没加 playsinline，iOS Safari 会强制全屏播放，不仅破坏布局，还会中断循环逻辑，甚至让 ontimeupdate 监听失效。
- 必须写成
<video loop muted autoplay playsinline></video>，四个属性缺一不可 -
playsinline在 Android 和桌面 Chrome 中无害，但某些国产 WebView（如 QQ 浏览器）也要求它才允许内联播放 - 真机测试比模拟器重要得多——iOS 模拟器常不触发自动播放限制，而实机在低电量、后台恢复、或页面滚动后极易中断循环
最容易被忽略的是：所有这些 JS 干预都建立在 video.readyState === 4（HAVE_ENOUGH_DATA）基础上。如果视频还没加载完就监听 ontimeupdate，video.duration 可能是 NaN，导致条件永远不成立。务必先等 loadedmetadata 事件再绑定逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
