默认只播一次；loop是布尔属性，未设置即不循环，常见循环误判源于残留代码、JS监听ended事件或旧标签；iOS Safari等会因策略忽略autoplay+loop组合。
不加 loop 就是默认只播一次
HTML <audio> 标签的 loop 属性是开关式控制：显式写上 loop 或 loop="true" 才会循环；只要不写，浏览器就按规范默认只播放一遍。这不是“隐式行为”，而是标准定义——loop 是布尔属性，不存在“未设置即循环”的逻辑。
常见误解是删掉 loop 后仍循环，那大概率是：
– 代码里其实残留了 loop（比如复制粘贴没清干净）
– JS 脚本手动调用了 audio.addEventListener('ended', () => audio.play())
– 或者用了旧式 <embed> 标签，它的 loop="false" 才真能关循环（但已淘汰）
为什么加了 loop 还只播一次？检查这三点
写了 loop 却没循环，不是属性失效，而是被更高优先级机制覆盖：
-
loop和autoplay同时存在时，部分 iOS Safari 版本会忽略loop（尤其在无用户手势触发的上下文中） - JS 调用
pause()或load()后，loop状态可能被重置，需手动再设audio.loop = true -
<source>切换后，新加载的资源不继承原<audio>的loop值，得在oncanplaythrough里重新赋值
想确保单次播放，别只靠“不写 loop”
依赖默认行为不够稳健，尤其在 JS 动态控制场景下。更可靠的做法是主动清除循环意图：
立即学习“前端免费学习笔记（深入）”；
- 明确写
loop="false"（虽然非必需，但语义清晰） - 监听
ended事件，播放结束后立刻audio.currentTime = 0并audio.pause()，避免意外续播 - 若用 JS 创建音频实例，初始化时直接设
audio.loop = false，不依赖 HTML 属性解析
注意：iOS 上 ended 事件有时延迟或丢失，建议搭配 ontimeupdate 检查 currentTime >= duration - 0.1 作为兜底判断。
autoplay + loop 组合在移动端基本不可靠
桌面 Chrome/Firefox 对 autoplay loop 支持尚可，但 iOS Safari 和 Android Chrome 会直接禁用——即使加了 muted，loop 也常被忽略。这不是 bug，是策略限制：系统认为“自动+无限循环”对用户干扰过大。
真实项目中，如果需要背景音效循环，应改用 Web Audio API 的 AudioBufferSourceNode + loop = true，它不受 HTML 媒体策略约束；而 <audio> 更适合播单次语音、播客片段这类有明确起止意图的内容。
