高兼容性音频架构依赖分层隔离、降级兜底和用户交互前置；需全局单audio实例、强制load()、静音初始化、手势触发播放、Web Audio检测fallback、多格式src兜底及正确MIME类型。
直接说结论：高兼容性音频架构不是靠堆功能，而是靠分层隔离 + 降级兜底 + 用户交互前置。浏览器对 audio 元素和 Web Audio API 的支持差异极大，尤其在 iOS Safari、旧版 Android WebView 和部分国产浏览器中，不按套路来，play() 就会静音或抛 NotAllowedError。
只用一个 audio 实例，所有播放逻辑复用它
多个 audio 标签并存是兼容性灾难的起点——iOS 会限制同时激活的音频上下文数，Android WebView 可能无法释放前一个实例的系统资源，导致后续 play() 失败或延迟。
- 整个项目只声明一个全局
<audio id="main-audio"></audio>，所有歌曲切换都通过audio.src = newUrl+audio.load()+audio.play()流程完成 -
audio.load()不可跳过：否则 MP3 文件头未加载完时调用play()，Safari 可能卡住或报错 - 避免把
audio嵌在每个列表项里——DOM 膨胀不说，还容易触发多实例自动播放拦截
自动播放必须绑定用户手势，且默认静音
Chrome、Safari、Firefox 全部要求首次 play() 必须发生在用户点击、触摸、键盘事件等“可信事件”回调内，否则直接拒绝。静音是唯一稳定绕过限制的合法方式。
- 初始化时设置
audio.muted = true，并在用户点击“播放”按钮后才尝试audio.muted = false - 不要依赖
autoplay属性：它在绝大多数移动端无效，且现代桌面浏览器也默认禁用非静音 autoplay - 若需“一进页面就播”，只能引导用户点一次按钮（哪怕是个透明 overlay），再执行播放逻辑
Web Audio API 使用前必须检测并 fallback
Web Audio API 在 IE 完全不支持，iOS Safari 14.5 之前不支持 createMediaElementSource，部分安卓浏览器对 analyser 的 fftSize 支持不一致。不能假设它一定可用。
立即学习“前端免费学习笔记（深入）”；
- 创建上下文前先判断：
const AudioContext = window.AudioContext || window.webkitAudioContext;，如果为undefined，直接退回到纯audio控制逻辑 - 连接
analyser后务必连到destination：漏掉这步，声音会消失，但控制台无报错，极难排查 - 移动端首次调用
audioContext.resume()必须在用户手势回调内，否则 context 保持suspended状态，后续所有节点都不工作
格式与路径必须双保险，不依赖单一 MIME 类型
不同浏览器对 .mp3、.ogg、.wav 的支持程度不同，且某些企业内网环境会拦截非标准 MIME 类型响应，导致 audio 加载失败静默。
-
<source>标签至少提供两种格式，顺序按兼容性从高到低排：mp3（全平台）、ogg（Firefox/Chrome） - 服务端返回音频时，确保
Content-Type正确：MP3 必须是audio/mpeg，不是audio/mp3或application/octet-stream - 路径尽量用相对路径或完整 HTTPS URL；避免使用 file:// 协议，本地双击打开 HTML 时多数浏览器会因跨域策略禁用音频
真正麻烦的不是写几行 play()，而是当用户在微信内置浏览器点播放却没声、在钉钉桌面端切歌后卡住、在 iOS 微信里第一次点不动——这些场景的修复逻辑必须提前埋进架构里，而不是出问题了再 patch。
