loop属性不处理缓冲区衔接，仅触发重新加载导致黑场；无缝循环需用ended或timeupdate事件配合currentTime=0实现，并优先选用.ogg或.wav格式。
loop 属性根本不会处理缓冲区衔接
它不负责、也不参与任何缓冲区管理。所谓“无缝”，是指播放末尾到开头之间无静音间隙，而 loop 只是告诉浏览器：“播完后跳回 0 秒重新加载并播放”。这个“重新加载”过程会清空解码器状态、重置缓冲区，导致天然存在 100–500ms 的黑场——不是你没配对，是它压根没这功能。
常见误判现象：loop="true" 写了但仍有卡顿；audio.loop = "true" 赋字符串值后失效；MP3 文件在 Chrome/Safari 中循环点飘移。
-
loop是布尔属性，只认“是否存在”，写成loop="true"、loop="loop"或loop=""都等价于没写（除空字符串外，其他值会被忽略） - JS 中必须用布尔值：
audio.loop = true，不是字符串 - 一旦调用
audio.load()，loop 状态保留，但若之前被设为false，需手动恢复
真正影响缓冲区衔接的是音频格式与解码器行为
MP3 文件头信息不统一，解码器对循环点识别不准，Chrome 和 Safari 尤其明显；.ogg（Vorbis）和 .wav 在缓冲衔接上更稳定，实测间隙常低于 10ms。这不是“换 CDN”或“加 preload”能解决的，是格式层限制。
不要只提供 MP3：用 <source> 声明多格式，让浏览器自选最合适的解码路径：
<audio> <source src="bgm.ogg" type="audio/ogg"> <source src="bgm.mp3" type="audio/mpeg"> </audio>
- 避免用在线转码工具草率转换——可能破坏原始循环点
- 推荐用 Audacity 或 FFmpeg 重导出，并勾选“无间隙导出”选项
- 小体积背景音效可优先试 .wav：免解码延迟，且现代浏览器对短 wav 的缓冲复用更积极
需要无缝就得绕过 loop，用 ended + currentTime 控制缓冲时机
监听 ended 事件，在播放自然结束瞬间执行 currentTime = 0 + play()，能跳过浏览器默认的 reload 流程，直接复用已有缓冲区（前提是资源已 fully loaded）。
但必须满足三个硬条件：
- 首次播放必须由用户手势触发（如 click/touch），否则
play()会被静音或拒绝 - 跳转前检查
audio.readyState >= audio.HAVE_FUTURE_DATA，否则currentTime = 0可能静默失败 - 加
.catch()捕获拒绝：iOS Safari 在非交互上下文中会抛DOMException: The play() request was interrupted
示例关键逻辑：
audio.addEventListener('ended', () => {
if (audio.readyState >= audio.HAVE_FUTURE_DATA) {
audio.currentTime = 0;
audio.play().catch(e => console.warn('循环触发被阻止:', e));
}
});iOS Safari 的 ended 事件不可靠，得用 timeupdate 提前干预
iOS Safari 的 ended 仅在“正常播放结束”时触发。网络波动、缓冲中断、或音频未完全解码就到末尾，它就不发事件——这不是 bug，是设计行为。此时依赖 ended 会卡死在末尾。
实操方案是监听 timeupdate，在到达末尾前 80ms 主动跳转：
let isJumping = false;
function handleLoop() {
if (!audio.duration || audio.readyState < 2 || isJumping) return;
const remaining = audio.duration - audio.currentTime;
if (remaining < 0.08) {
isJumping = true;
audio.currentTime = 0;
setTimeout(() => { isJumping = false; }, 100);
}
}
audio.addEventListener('timeupdate', handleLoop);这个提前量（0.08s）要根据音频实际长度和格式微调；太小易漏判，太大则引入可感知停顿。真正的难点不在代码怎么写，而在不同设备、不同网络条件下，这个阈值是否稳定——它没法一劳永逸。
