autoplay属性在现代浏览器中基本无效，除非音频静音或用户已交互；各浏览器均要求muted、可信用户事件及HTTPS环境，iOS和微信WebView限制更严，需预激活每个audio元素。
直接说结论：autoplay 属性在现代浏览器里基本“形同虚设”，除非音频是静音的，或者用户已经和页面发生过交互——这是硬性策略，不是 bug，也不是兼容性问题。
为什么 play() 会抛 NotAllowedError
Chrome、Firefox、Safari 和 Edge 都遵循同一套媒体自动播放策略：只有满足以下任一条件，才能播放带声音的音频：
- 音频元素设置了
muted="true" - 用户已触发过
click、touchstart、keydown等可信事件（注意：scroll、mousemove不算） - 页面来自 HTTPS（HTTP 下部分策略更严，尤其 iOS）
错误信息长这样：DOMException: play() failed because the user didn't interact with the document first。它不会中断 JS 执行，但 play() 返回的 Promise 会被 reject，不 catch 就看不到提示。
iOS Safari 和微信 WebView 的特殊限制
这两类环境比桌面浏览器更保守：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 即使加了
muted，首次播放仍需用户 touch 启动（touchstart或click） - 微信 iOS WebView 会忽略
autoplay和muted，必须等WeixinJSBridgeReady事件后调用play() - 所有音频元素必须在用户首次交互时“预激活”：对每个
<audio>元素执行一次play().then(() => pause())，否则后续play()仍会失败
别指望靠 setTimeout 延迟播放绕过——iOS 会判定为非用户驱动，直接拦截。
如何让背景音乐“真能播”，且不被静音
目标是“有声自动播放”，不是“静音后让用户点开再调大音量”。可行路径只有一条：把首次交互设计成自然触发点，比如“开始体验”按钮、弹窗确认、或页面滚动到底部后的浮层点击。
- 不要把
play()放在window.onload或DOMContentLoaded里——没用 - 绑定到用户可感知的操作上，例如：
document.querySelector('#start-btn').addEventListener('click', () => audio.play()) - 调用前确保资源已加载：监听
loadedmetadata事件后再play()，避免因元数据未就绪导致失败 - 加
.catch(e => console.warn('play blocked:', e))，方便定位是策略拦截还是路径/格式问题
真正容易被忽略的是：多个音频元素要分别预激活，不能只播一个就认为“全通了”。iOS 对每个 <audio> 实例单独校验用户手势上下文。
