动态创建audio必须在用户手势回调中首次调用play()且先设muted=true；需为每个source设置src和type；preload="metadata"可控制加载量，但ios safari忽略。
audio元素动态创建后为什么没声音或报错
直接用document.createElement('audio')新建音频节点，再appendChild进页面，大概率会遇到：播放失败、控制台静默无提示、或触发DOMException: play() failed because the user didn't interact with the document first。这不是创建方式错了，而是动态插入的audio仍受浏览器 Autoplay Policy 约束——它和静态 HTML 中写的<audio></audio>一样，首次play()必须发生在用户手势（click/touchstart）之后。
- 动态创建的
audio默认不继承父容器的交互上下文，即使它被插在已点击过的<div>里，也得自己“重新获得许可” <li>如果在<code>DOMContentLoaded或setTimeout中调用play()，100%失败；必须绑定到真实的用户事件回调里 -
muted = true仍是前置条件：哪怕你后续要开声，也得先以静音状态完成首次play()调用，否则 Promise 直接 reject - 动态创建时，用
audio.appendChild(sourceEl)逐个添加<source></source>，每个都带src和type：sourceEl.type = 'audio/mpeg' - 不要依赖
canplay事件就立刻play()——它只表示“能播了”，不代表“已获用户许可”。仍需确保该调用发生在 click 回调内 - 加载失败时，
error事件只在对应<source></source>上触发，不是audio本身。所以监听要挂到每个source上，或统一用audio.networkState === HTMLMediaElement.NETWORK_NO_SOURCE判断兜底 - 动态创建后立即设
audio.preload = 'metadata'，再load()触发元数据加载；别等src赋值完自动触发，时机不可控 - 注意：iOS Safari 下
preload基本被忽略，它总按自己的策略来；但 Android Chrome 和桌面端效果稳定 - 如果音频极短（preload="auto"，避免首次播放延迟
- 必须用
touchstart而非click监听首次交互（iOS 上 click 有 300ms 延迟，可能错过窗口） - 在
touchstart回调里，立即调用audio.load()+audio.play()，中间不要加任何异步操作 - 如果音频还没加载完，
play()会失败；所以最好提前在页面空闲时用preload="metadata"预热，或用canplaythrough事件做二次保障
如何用 JavaScript 安全加载并播放多格式音频
不能只靠一个src属性赌兼容性。现代浏览器对type声明敏感，尤其 Safari 和旧版 Edge 会跳过没写type的<source></source>；而服务端若没返回正确 Content-Type（如 MP3 返回audio/mpeg），即使路径对也会加载失败。
preload="metadata"在动态加载中的实际作用
设preload="metadata"不是为了“快”，而是为了“可控”。对长音频（比如 >5MB 的语音讲解），preload="auto"会让浏览器尝试下载全部内容，拖慢首屏、浪费流量；而metadata只取时长、采样率等头部信息，几 KB 就完事，duration能读到，play()也能立刻响应。
移动端 iOS Safari 的特殊限制怎么绕过
iOS Safari 是最严的：不仅禁自动有声播放，还要求音频能力必须由**首次触摸事件**解锁，且之后所有play()必须在同一个事件循环内完成——跨setTimeout或 Promise.then 就失效。更麻烦的是，它不支持play()返回的 Promise，只抛同步异常。
真正难的不是写几行 JS 创建 audio，而是让同一段代码在 Chrome、Firefox、Safari、微信内置浏览器里都走通。关键不在“怎么加载”，而在“什么时候加载”和“谁给它放行”。漏掉一次muted，或在错误时机调play()，整个链路就断了——这种问题往往只在真机上暴露，本地开发看不出来。
