controls和loop是独立布尔属性，controls仅控制原生控件显示，loop仅在正常播放结束时触发重播；因浏览器策略、加载失败、用户手势缺失等原因，loop常失效；可靠循环需监听ended事件并手动重置currentTime。
controls 和 loop 是两个独立作用的布尔属性，它们不互相依赖，也不能组合出“带控制条的循环播放”这种理想状态——controls 只决定是否显示原生控件，loop 只在音频**正常播放结束**时触发重播；而现代浏览器（尤其是移动端）常因策略拦截导致 loop 根本没机会执行。
为什么加了 loop 却不循环？常见失效链路
不是代码写错了，而是播放流程在某个环节断掉了：
-
src路径错误或返回 404，network 面板能看到请求失败，此时play()被静默拒绝，ended事件永远不会触发 - 未触发用户手势（如点击、触摸），Chrome/Safari 会阻止自动播放，
autoplay+loop组合在桌面端也大概率被静音，移动端直接无效 -
preload="none"且未手动调用load()，音频元数据未加载，duration为NaN，ended事件无从谈起 - iOS Safari 中音频缓冲中断（比如网络抖动），播放卡在末尾但不触发
ended，因为这不是“正常结束”，只是异常终止
controls 属性的真实作用与局限
controls 仅渲染浏览器内置控件，它不参与任何播放逻辑控制，也不影响 loop 是否生效。但它会暴露一个隐藏风险：
- 用户点击原生“循环按钮”（如果浏览器提供了）时，实际是切换
audio.loop属性值，但这个操作无法监听，也无法与 JS 状态同步 - 一旦启用了
controls，用户可随时拖拽进度条、点击暂停，这些行为会打断你用 JS 实现的循环逻辑（比如timeupdate中的跳转） - 某些旧版 Safari 在
controls开启时，对currentTime的设置响应延迟，导致分段循环跳转不准
真正可控的循环：用 ended 事件 + currentTime 重置
绕过 loop 的不可靠性，监听 ended 并手动控制时间点，才是跨平台稳定的方案：
立即学习“前端免费学习笔记（深入）”；
const audio = document.querySelector('audio');
const handler = () => {
audio.currentTime = 0;
audio.play().catch(e => console.warn('自动重播被阻止:', e));
};
audio.addEventListener('ended', handler);
// 后续可随时关闭循环
// audio.removeEventListener('ended', handler);
- 必须确保首次
play()由用户手势触发（例如按钮click），否则后续play()调用会被拒绝 - 不要在
ended回调里直接写audio.currentTime = 0; audio.play();，需用变量缓存 handler，方便解绑 - 若要支持“只循环某一段”，不能依赖
loop，得用timeupdate+ 状态标记（如audio.loopingSegment）来判断跳转时机
移动端 iOS Safari 的硬性约束必须前置处理
iOS Safari 不允许任何非用户手势触发的音频播放，哪怕 muted + autoplay 也不行。这意味着：
- 不能靠
setTimeout延迟play()来绕过，策略检测发生在调用瞬间 - 不能用
volume = 0模拟静音，iOS 仍视为“有声流”，同样受阻 - 唯一合规路径：页面上放一个显眼按钮（如「开启背景音乐」），绑定
audio.play()，成功后保存状态用于后续循环 - 若需默认启用且不依赖按钮，只能降级使用
AudioContext手动调度 buffer，但会失去volume、pause等原生控制能力
最麻烦的从来不是怎么写循环，而是怎么让循环行为符合预期：什么时候该停、跳到哪一秒、是否允许用户拖拽打断——这些都得靠 JS 状态管理，loop 属性只是个开关，连“开”了之后怎么转都不知道。
