原生loop属性无法实现无缝循环，因只控制播放逻辑而不处理帧衔接、解码缓冲及音频队列清空，导致50–200ms黑屏或静音间隙；mp3格式、未faststart的mp4、ios safari限制及错误赋值（如loop="true"）均加剧该问题。
原生 loop 属性做不到无缝循环——它只负责“播完再播一遍”，不处理帧衔接、解码缓冲或音频队列清空，50–200ms 的黑屏或咔哒声是正常行为，不是你写错了。
video 标签 loop 属性为什么有黑屏间隙
浏览器把 loop 当作播放逻辑开关，而非媒体流调度指令。视频末尾帧渲染后，播放器要清空解码器状态、重置音频缓冲、重新定位到开头，这个过程无法跳过。即使你写了 <video loop autoplay muted></video>，间隙依然存在。
-
loop是布尔属性，只认“存在与否”，loop="true"或loop=""都无效 - MP4 文件若没加
-movflags +faststart，duration初始为NaN，时间判断直接失效 - iOS Safari 在非用户手势触发下，
play()可能被静音或中断，导致 JS 补救失败
audio 标签 loop 属性为什么有静音间隙
MP3 格式本身对循环点支持差：ID3 标签位置不统一、解码器对末尾帧识别不准，Chrome 和 Safari 实测常有 100ms+ 静音。这不是 bug，是格式限制。
-
loop必须在loadedmetadata或canplay后设置才生效；preload="none"会导致元数据未加载，loop被忽略 -
audio.loop = true必须用布尔值，赋字符串"true"无效 - WebM（Vorbis）或 WAV 更可靠，实测间隙可压到
提供多格式回退
用 ontimeupdate 或 ended 事件手动接管循环
真正可控的方式是绕过原生 loop，用 JS 主动管理跳转时机——关键不是“等结束”，而是“提前拦截”。
- 对
video：监听ontimeupdate，当currentTime >= duration - 0.05时设currentTime = 0，并调play().catch(() => {}) - 对
audio：监听ended，但必须先检查readyState >= HAVE_FUTURE_DATA，否则currentTime = 0失败 - 加标志位（如
isJumping）防重复触发；iOS 上首次play()必须由用户点击触发
高精度场景必须用 Web Audio API
如果需要节拍同步、实时叠加音效或毫秒级控制，HTML audio 标签的任何方案都会抖动。唯一真正无缝的是 AudioContext + AudioBufferSourceNode。
- 用
fetch()加载音频，decodeAudioData()解码成AudioBuffer - 靠
start(when, offset, duration)的offset和duration参数切片循环，不依赖浏览器解码器 - iOS 上
AudioContext必须在用户手势回调中首次resume()，否则静音
最易被忽略的点是：无论用哪种 JS 方案，视频首尾帧内容不对齐、音频末尾有淡出/静音帧、服务端缺失 Accept-Ranges: bytes 响应头，都会让“无缝”变成“明显卡顿”。这些不在代码里，但在实际效果里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
