现代浏览器禁止无用户交互的音频自动播放，必须在click或touchstart等用户手势事件中调用audio.play()并捕获Promise错误，muted无法可靠绕过限制。
Audio.play() 调用失败：常见报错和触发条件
直接调用 audio.play() 报错 DOMException: play() failed because the user hasn't interacted with the document yet，这是现代浏览器（Chrome 66+、Safari、Edge）的强制策略：没有用户手势（如 click、touchstart）触发的音频播放会被静音或拒绝。
- 自动播放只在满足“用户已交互”前提下才可能成功，页面加载完立即
play()必然失败 - 即使设置了
autoplay属性，也会被忽略（除非同时满足静音 + 用户交互历史等极少数例外） - 部分安卓 Chrome 对
muted+autoplay更宽松，但 iOS Safari 仍严格限制
必须用用户事件触发播放：click 是最稳妥的入口
把 play() 放在用户可触发的事件回调里，是最可靠的做法。注意不是所有事件都有效 —— scroll、mousemove、load 都不算“有意向的用户交互”，只有明确由用户主动发起的事件才行。
- 推荐使用
click或touchstart（移动端），它们被所有主流浏览器认可为合法播放触发源 -
keydown也可用，但需确保是真实按键（比如空格键、回车键），且不能在 iframe 或失焦状态下触发 - 避免在
setTimeout或异步回调中“延迟调用play()”，一旦脱离事件上下文，就失效
示例：
静音音频可绕过部分限制，但不解决核心问题
设置 muted 属性后，Chrome 允许 autoplay，但这只对视频元素真正有用；对纯 ，即使 muted，多数浏览器仍要求用户交互才能开始播放（iOS 尤其严格）。
-
在桌面 Chrome 可能“看似成功”，但实际音频未输出（无声音），且play()Promise 不一定 resolve - 不要依赖
muted来实现“无感自动播放”，它不是通用解法 - 如果业务允许，用
播放无声视频作为占位，再在用户点击后切换为有声音频，更可控
播放失败后的错误处理不能省略
audio.play() 返回 Promise，失败时会 reject，不捕获会导致 unhandled rejection，且无法得知具体原因（是被拦截？文件 404？格式不支持？）。
立即学习“前端免费学习笔记（深入）”；
- 务必用
.catch()捕获错误，并根据e.name区分类型："NotAllowedError"表示权限拒绝，"NotFoundError"表示资源不存在 - 失败后可降级：显示按钮、提示用户点击、或 fallback 到 Web Audio API 手动解码（复杂度高，一般不必要）
- 不要反复重试
play()—— 浏览器不会因为多试几次就突然允许
