现代浏览器禁止有声音频自动播放，必须满足muted=true且用户交互触发；iOS Safari和微信WebView更严格，需预激活每个audio实例并绑定可信事件。
现代浏览器里，autoplay 属性对有声音频基本无效——这不是 bug，是强制策略。想让它“真能播”，必须满足 muted + 用户交互二者之一，且移动端（尤其是 iOS Safari 和微信 WebView）还有额外校验。
为什么 play() 会抛 NotAllowedError
Chrome、Firefox、Safari、Edge 都遵循同一套媒体自动播放策略：只有满足以下任一条件，才能播放带声音的音频：
-
muted="true"显式设置（仅volume="0"不生效） - 用户已触发
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，首次播放仍需用户touchstart或click启动 - 微信 iOS WebView 会完全忽略
autoplay和muted，必须等WeixinJSBridgeReady事件后调用play() - 所有
<audio>元素必须在用户首次交互时“预激活”：对每个实例执行一次play().then(() => pause())，否则后续调用仍失败 -
setTimeout延迟播放无效——iOS 会判定为非用户驱动，直接拦截
如何让背景音乐“真能播”，且不被静音
目标是“有声自动播放”，不是“静音后让用户点开再调大音量”。可行路径只有一条：把首次交互设计成自然触发点。
- 不要把
play()放在window.onload或DOMContentLoaded里——没用 - 绑定到用户可感知的操作上，例如：
document.querySelector('#start-btn').addEventListener('click', () => audio.play()) - 调用前确保资源已加载：监听
loadedmetadata事件后再play()，避免因元数据未就绪导致失败 - 加
.catch(e => console.warn('play blocked:', e))，方便区分是策略拦截还是路径/格式问题
真正容易被忽略的是：多个音频元素要分别预激活，不能只播一个就认为“全通了”。iOS 对每个实例单独校验用户手势上下文。
