现代浏览器默认禁止有声音频自动播放，必须先设置muted+autoplay实现静音自动播，再通过用户交互（如点击）调用play()并取消静音；preload影响加载时机但不影响播放策略，iOS等移动端限制更严。
audio 标签加 autoplay 属性没用？先看浏览器策略
现代浏览器（Chrome、Firefox、Safari、Edge）默认禁止有声音的音频自动播放，除非用户已与页面交互过（如点击、触摸）。这是硬性策略，不是 bug，加了 autoplay 但没声音或没触发，大概率是这个原因。
真正能“静音自动播”的唯一可靠路径是：同时设置 muted + autoplay。即使你本意是想播有声内容，也得先走这一步——否则连加载都不会开始。
-
可立即播放（静音） - 后续通过 JS 调用
play()并取消静音，可能成功（取决于用户是否已交互） - 纯
autoplay在移动端几乎 100% 失效；桌面端新标签页首次打开也常被拦截
如何在用户交互后恢复有声播放
必须等用户主动触发（比如点击按钮、触摸区域），再调用 play() 并移除 muted。不能靠定时器或页面加载完成就执行，否则会被浏览器拒绝并抛出 NotAllowedError。
典型安全写法：
立即学习“前端免费学习笔记（深入）”；
- 不要在
DOMContentLoaded或window.onload里调play() -
play()返回 Promise，务必用.catch()捕获拒绝（常见错误信息：NotAllowedError: play() can only be initiated by a user gesture） - 部分安卓 WebView 对
muted后再取消静音仍限制严格，建议优先用用户点击触发完整流程
preload 和 loop 的配合要点
preload 影响的是音频资源何时开始加载，和自动播放能否成功无关，但它会影响用户体验延迟：
-
preload="auto"：页面加载时即开始下载音频（适合小文件、确定要播） -
preload="metadata"：只加载时长、封面等元数据（节省带宽，适合列表页预览） -
preload="none"：完全不预加载（用户点播才开始请求，首播延迟明显） -
loop可以和autoplay共存，但若音频被静音拦截，loop也不会起作用
注意：preload 值不是布尔值，别写成 preload="true" —— 浏览器会忽略它。
移动端特别注意事项
iOS Safari 对音频控制最严格：即使用户点过页面，play() 仍可能失败，除非音频元素已在 DOM 中且已设置 src（不能动态 append 后立刻播）。
- 音频
标签必须在 HTML 中提前写好，或至少在用户交互前插入并设好src - 避免用
new Audio(src).play()动态创建——iOS 几乎必定拒绝 - 某些安卓机型（尤其国产定制系统）会把「页面滚动」也当作用户交互，但不可靠，仍应绑定明确点击事件
- 如果目标是背景提示音（如通知、倒计时结束），考虑降级用 Web Audio API +
oscillator生成简单音效，它不受 autoplay 策略限制
真正的难点不在怎么写代码，而在判断“用户是否已完成有效交互”——这个状态无法准确探测，只能靠设计上强制一个明确操作入口。
