loop属性无法实现真正无缝循环，因HTML原生行为导致毫秒级停顿；MP3末尾静音、编解码差异及浏览器实现不一致加剧“咔哒”声；JS手动跳转风险高且受限于preload和iOS交互限制；Web Audio API是可靠方案，但需预加载、缓冲区交替播放、显式断连，并依赖音频文件本身无静音、带淡出处理。
loop 属性本身做不到真正无缝循环——它只是让浏览器在播放结束时跳回开头，中间必然存在毫秒级停顿。这不是你写错了，而是 HTML 原生行为限制。
为什么 loop 会咔哒一声？
MP3 文件末尾普遍有 10–200ms 的填充静音或不完整编码帧，loop 会原样暴露这段空白；Ogg/Vorbis 和 AAC（.m4a）表现稍好，但依然依赖文件是否经过专业导出；Chrome 和 Safari 对 loop 的底层实现不同，同一文件可能在一个浏览器里安静，在另一个里“啪”一下。
用 timeupdate + currentTime = 0 行不行？
可以临时补救，但风险高：
-
preload="none"或preload="metadata"会导致timeupdate触发不稳定，跳转时机错乱 - 必须设
preload="auto"才能保障定时精度，代价是首次加载体积略大 - 移动端 iOS Safari 会拦截
audio.play()，除非由用户真实点击触发，否则直接报DOMException: play() failed because the user didn't interact with the document first - 手动跳转容易和原生
loop冲突，建议检测到audio.loop === false时再启用 JS 补偿
真正靠谱的无缝方案：Web Audio API 手动衔接
绕过 <audio> 标签限制，用 AudioContext 精确控制缓冲区播放：
立即学习“前端免费学习笔记（深入）”；
- 必须用
context.decodeAudioData(buffer)预加载，不能直接src—— 否则拿不到duration和精确起始时间 - 核心是两个
BufferSourceNode交替启动：source.start(startTime)中的startTime设为前一段的audioBuffer.duration - 每次
onended后要显式调用node.disconnect()，否则内存泄漏 - 不支持 IE，且无法直接响应系统音量/静音开关，需自行封装混音逻辑
最易被忽略的一点：无缝不靠代码靠音频本身——哪怕用了 Web Audio API，如果原始文件结尾带静音、没做淡出，照样会咔。务必用 Audacity 裁掉末尾空白，并对最后 5–10ms 淡出。否则所有技术方案都在对抗一个本可避免的问题。
