不能完全依赖 loop 属性实现无缝循环；其在 safari（尤其 ios）中存在毫秒级静音间隙，需结合 js 监听 ended 事件、重置 currenttime 并 play()，且首次播放必须由用户手势触发。
audio 标签的 loop 属性是否真能可靠循环？
不能完全依赖 loop 属性实现无缝循环。浏览器对 loop 的实现存在差异：Chrome 和 Edge 通常能较好支持，但 Safari（尤其是 iOS）会强制在循环点插入微小静音间隙，甚至偶尔跳过末尾帧导致“卡顿感”。这不是 bug，而是音频解码与缓冲机制导致的固有行为。
实际使用中，如果背景音乐是纯氛围型（如环境白噪音、无强节奏的钢琴曲），loop 可用；但若有明确节拍、鼓点或人声收尾，用户大概率会感知到断层。
如何让 background music 真正“听不出停顿”？
绕过 loop 属性，改用 JavaScript 主动控制播放时机。核心思路是监听 ended 事件，在音频结束前几毫秒（如 50ms）调用 currentTime = 0 并 play()，避免自然停止带来的解码重置延迟。
- 必须设置
preload="auto"，否则首次循环可能因加载延迟而中断 - 需捕获
play()的 Promise 拒绝（如用户未交互触发播放），并在click或touchstart后再初始化音频 - 对同一
<audio></audio>元素频繁currentTime = 0+play()在旧版 Firefox 中可能失败，建议复用实例而非反复创建
<audio id="bgm" src="music.mp3" preload="auto"></audio><script>
const audio = document.getElementById('bgm');
audio.addEventListener('ended', () => {
audio.currentTime = 0;
audio.play().catch(e => console.warn('Auto-play prevented:', e));
});
// 必须由用户手势触发一次 play() 才能解锁后续自动播放
document.body.addEventListener('click', () => audio.play(), { once: true });
</script>
移动端 iOS Safari 的特殊限制怎么破？
iOS Safari 要求音频必须由用户直接手势触发（click/touchend），且不支持 autoplay 即使设置了 muted。这意味着：你无法在页面加载后自动开始背景音乐，也不能靠 setTimeout 延迟播放来绕过。
- 唯一合规做法：提供一个显眼按钮（如「开启背景音乐」），绑定
play()，并在成功后保存状态用于后续循环 - 不要尝试用
volume = 0模拟静音播放来“欺骗”策略——iOS 仍判定为非静音流，同样受阻 - 若必须默认启用，可降级为 Web Audio API 加载短音频 buffer 循环播放（但需手动混音、无原生音量/暂停控制）
为什么用
有人试图把 MP3 编码成 base64 放进 background-image: url(data:...) 来“隐藏”音频，这是无效的。CSS 不解析音频数据，浏览器不会将其识别为可播放媒体。该写法既不触发任何音频解码，也无法绑定事件或控制播放状态。
真正需要轻量级、免请求的方案，应使用 <audio></audio> 配合 src 为 data URL：<audio src="data:audio/mpeg;base64,..."></audio>。但注意：data URL 过大会阻塞 HTML 解析，且无法被缓存，仅适合几秒内的提示音。
背景音乐时长普遍超过 30 秒，务必走独立文件加载路径，并配合 preload 和懒加载逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
