必须在用户点击、触摸等可信事件中调用play()，且每个audio元素需单独预激活；muted可绕过部分限制但ios仍需首次手势，静音后取消静音仍需新交互。
audio.play() 报 DOMException: play() failed because the user didn't interact with the document first 怎么办
这是浏览器明确拒绝播放的信号，不是代码写错了，而是触发时机不合规。它发生在你调用 play() 时，当前文档尚未获得“用户激活”（user activation）上下文。
常见错误现象包括：页面一加载就执行 play()、在 window.onload 或 DOMContentLoaded 里调用、用 setTimeout 延迟几秒再播——这些全被拦截，iOS 尤其严格。
- 必须绑定到可信用户手势事件：如
click、touchstart、keydown（注意scroll和mousemove不算） - 每个
audio元素需单独激活：不能只对一个元素调一次play()就认为“全局解锁”，iOS Safari 对每个实例独立校验 - 首次交互后，激活状态仅维持约 5 秒；超时或页面失焦（如切标签页）后，
play()会再次失败 - 务必加
.catch(e => console.warn('play blocked:', e))，否则 Promise reject 无声无息
muted="true" 能绕过限制吗？哪些场景真有效
能，但有前提：muted 必须显式写出，且音频资源已加载完成。它适用于背景音乐、环境音效等无需初始音量的场景。
关键细节：
-
muted是布尔属性，写成muted="true"或muted="muted"都合法，但volume="0"完全无效 - 桌面 Chrome/Firefox 在
muted+autoplay下可立即播放；Safari 桌面版也支持 - iOS Safari 和微信 WebView 仍要求首次播放由用户 touch/click 启动，哪怕 muted —— 所以得先绑一次
touchstart再play() - 静音自动播放 ≠ 后续能取消静音：iOS 上取消
muted并调play()仍需新用户手势，不能靠之前那次激活
loop 属性为什么循环有间隙？如何实现真正无缝
原生 loop 属性无法做到毫秒级无缝，这是浏览器解码器和播放管线的固有行为，尤其 MP3 格式最明显。这不是 bug，是设计限制。
如果你需要连续无中断的循环（比如白噪音、BGM 伴奏）：
- 放弃
loop属性，改用ended事件手动控制 - 在
ended回调中先调load()，再立即play()；不加load()容易因缓冲不足失败 - 确保此时用户已交互过（否则
play()仍抛NotAllowedError） - MP3 优先换为
.ogg测试，WAV 更可靠但体积大 - JavaScript 中设
audio.loop = true（布尔值），别写成字符串"true"
多个音频实例或页面失焦后恢复播放怎么处理
用户切走标签页、最小化窗口、系统休眠后，浏览器会重置 user activation 状态。此时任何 play() 都会失败，不是资源问题，是策略重置。
可行做法：
- 监听
visibilitychange事件，当document.hidden === false时，说明用户回来了，但此时仍无激活令牌 - 不能直接
play()，要等下一个用户手势（比如按钮点击）再触发；或提前展示一个轻量级交互入口（如“继续播放”浮层按钮） - 多个
audio实例不要共用一个激活逻辑：每个都得在用户首次交互后各自调一次play().then(() => pause())预激活 - 避免重复绑定：用
{ once: true }选项监听click或touchstart，防止多次注册导致内存泄漏
真正容易被忽略的是：iOS 对每个 audio 实例的激活上下文完全隔离，哪怕它们来源相同、加载顺序一致，也必须分别“握手”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
