HTML5 <audio> 的 loop 属性仅支持布尔值，无法设置具体循环次数；必须用 JavaScript 监听 ended 事件手动计数控制，或使用 AudioContext 实现精准调度。
HTML5 <audio> 标签不支持 loop 控制具体次数
直接说结论：loop 属性只有布尔值（true/false），它只决定“是否无限循环”，**无法设置播放 2 次、3 次等具体次数**。浏览器原生不提供 loop="3" 或类似语法，所有试图在 HTML 属性里填数字的写法都会被忽略或解析为 true。
常见错误现象：<audio loop="2"> 或 <audio loop="on"> 看似合理，但实际行为和 <audio loop> 完全一致——无限循环。
-
loop是一个布尔属性：存在即true，不存在即false - 即使写成
loop="0"或loop="false"，也会被当作存在而启用循环 - 想靠 HTML 属性实现“播放 3 次后停止”？行不通，必须用 JavaScript
用 audio.addEventListener('ended', ...) 手动计数控制循环次数
真正可行的方案是监听 ended 事件，在每次播放结束时递增计数器，达到目标次数后调用 pause() 并重置 currentTime（可选）。
关键点在于：不能依赖 loop = true，而要主动控制播放流程。
- 初始化时设
audio.loop = false（显式关闭原生循环） - 用
let playCount = 0和const maxLoops = 3管理状态 - 在
ended回调里判断：若playCount < maxLoops - 1，则audio.currentTime = 0; audio.play();；否则保持暂停 - 注意：多次调用
play()可能触发 Promise 拒绝（如用户未交互就自动播放），建议在用户手势（如 click）后首次调用play()再开启计数逻辑
const audio = document.querySelector('audio');
let playCount = 0;
const maxLoops = 3;
<p>audio.loop = false;
audio.addEventListener('ended', () => {
playCount++;
if (playCount < maxLoops) {
audio.currentTime = 0;
audio.play().catch(e => console.warn('Auto-play prevented:', e));
}
});使用 AudioContext + AudioBufferSourceNode 更精准控制（适合 Web Audio 场景）
如果背景音乐需要低延迟、精确调度、或与其他音频混合（比如游戏音效），<audio> 的事件模型会显得粗糙。AudioContext 提供基于时间线的播放控制，可以预设计划：第 0 秒播第 1 段，第 3.2 秒播第 2 段……自然也支持“只调度 3 次”。
缺点是代码量增加，且需处理音频解码（decodeAudioData），不适合简单页面背景音乐。
-
start(when)的when参数支持未来任意时间点，精度达毫秒级 - 每个
AudioBufferSourceNode只能start()一次，所以循环 N 次 = 创建 N 个节点或复用一个节点并多次start()（需重新设置buffer） - 没有内置“播放完成回调”，需自己用
setTimeout或context.currentTime推算结束时间来触发下一次 - 移动端对自动播放限制更严，
AudioContext必须在用户交互后首次resume()
容易被忽略的兼容性与体验细节
看似只是“循环几次”的小需求，实际落地时几个点常被跳过，导致在 iOS 或 Chrome 上静音、中断或卡住：
- iOS Safari 要求
audio元素必须有preload="auto"且用户至少触发过一次播放，否则play()会静默失败 - Chrome 88+ 对无用户交互的自动播放更激进，即使设置了
autoplay，若没声音或没用户手势，play()仍可能被拒 - 反复设置
currentTime = 0后play()，某些安卓 WebView 会出现极短空白帧或卡顿，可加audio.load()强制重载（但开销大，慎用） - 若背景音乐用于长页面，记得监听页面隐藏/显示（
visibilitychange），避免用户切走后还在后台循环消耗资源
真正难的不是写几行计数逻辑，而是让这几次播放在各种设备上都“不掉链子”——尤其是第一次播放能否响起来，往往决定了整个方案是否成立。
