video标签loop属性无法实现无缝循环，因存在50–200ms黑屏或卡顿；需用javascript监听ontimeupdate提前跳转currenttime至0，并处理autoplay限制、媒体封装（如faststart）及ios safari兼容性问题。
video 标签 loop 属性本身不保证无缝循环
浏览器原生 loop 属性只是让视频播完后自动跳回开头重放，但中间存在解码缓冲、帧定位、音频队列清空等延迟，通常会出现 50–200ms 的黑屏或卡顿。这不是 bug，而是规范行为——loop 只控制播放逻辑，不干预媒体流衔接。
真实场景下（比如数字标牌、展厅背景视频、UI 动效），用户感知到的就是“断了一下”。要消除这个间隙，必须绕过纯 HTML 声明式控制，改用 JavaScript 主动管理播放状态。
用 ontimeupdate + currentTime 手动触发跳转
在视频即将结束前（比如倒数 0.1 秒）主动设置 currentTime 回 0，比依赖自然结束更可控。关键不是“等到结束”，而是“提前拦截”：
- 监听
ontimeupdate，持续检查video.currentTime >= video.duration - 0.05 - 满足条件时立即执行
video.currentTime = 0，并调用video.play() - 必须加
video.play().catch(e => {})，因为部分浏览器在非用户手势触发下会拒绝继续播放 - 避免重复触发：设个标志位（如
isJumping），跳转后 100ms 内忽略后续判断
示例片段：
const video = document.querySelector('video');
let isJumping = false;
<p>video.ontimeupdate = () => {
if (isJumping) return;
if (video.currentTime >= video.duration - 0.05) {
isJumping = true;
video.currentTime = 0;
video.play().catch(() => {});
setTimeout(() => { isJumping = false; }, 100);
}
};</p>
HLS 或 MP4 封装方式影响实际效果
即使 JS 跳转逻辑写得再准，底层媒体格式和编码参数也会暴露缝隙：
- MP4 文件必须有
moovbox 在文件开头（即“fast start”），否则首次加载时无法快速获取时长，duration初始为NaN，导致时间判断失效 - HLS 流中，如果最后一段 TS 片段末尾有音频静音帧或编码 GOP 不齐，跳回开头时音频缓冲可能残留残影，听起来像“咔哒”声
- 推荐用 FFmpeg 预处理：对 MP4 加
-movflags +faststart；对 HLS，确保hls_time设置为 2–4 秒，并关闭hls_allow_cache=0避免 CDN 缓存旧分片
移动端 Safari 的特殊限制
iOS Safari 对自动播放和循环干预极严：
- 即使用户已交互过，
play()在currentTime修改后仍可能被静音或中断 - 必须确保视频含
muted和autoplay属性，且首次播放由用户点击显式触发（如按钮） - 某些 iOS 版本中，
ontimeupdate在后台标签页或锁屏状态下会大幅降频甚至暂停，导致跳转延迟——此时应 fallback 到onended事件（虽有间隙，但至少能播下去）
真正无缝只在桌面 Chrome/Firefox + 正确封装的 MP4 下最稳定；其他环境都要准备降级方案，比如用两段相同视频交替播放（video1 播完立刻 video2 接上），靠 CSS 切换 visibility 隐藏切换过程。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
