浏览器严格按source顺序加载，遇首个可解码格式即停止，故应按MP3→OGG→WAV排列；type必须精确为audio/mpeg、audio/ogg、audio/wav，且服务端Content-Type须完全匹配，否则跳过。
audio标签里顺序怎么排才不白写
浏览器严格按OGG 放 MP3 前面，Firefox 会播，但 Safari 直接卡住不动（它不支持 OGG），连后续的 MP3 都不试。
推荐顺序（音频）：MP3 → OGG → WAV。MP3 兼容性最广，iOS / Android / 桌面端通吃；OGG 是 Firefox 和部分 Linux 浏览器的首选；WAV 虽大但无压缩，作为兜底可避免完全失败。
-
type属性必须写，且要精确：MP3 对应audio/mpeg，OGG 对应audio/ogg，WAV 对应audio/wav - 漏掉
type，Safari 和旧 Edge 会忽略该source，甚至触发两次请求（先试一次没 type 的，再试下一个） - 服务器返回的 Content-Type 必须和
type值一致，否则 Chrome 会静默跳过
为什么加了还是只播第一个、根本不回退
常见现象是：MP3 加载失败（404 或 MIME 错），但页面没反应，也不切到 OGG。这不是回退失效，而是浏览器根本没触发错误流程——它只在“格式不支持”时跳转，而不是“文件不存在”时。
真正触发回退的条件只有两个：格式不支持 或 解码失败。404、跨域、file:// 协议被拒、路径含中文，这些都属于网络层失败，不会触发 source 切换，也不会抛 error 事件（多数浏览器静默处理）。
立即学习“前端免费学习笔记（深入）”；
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 开发阶段务必用本地服务跑（如
npx serve），别双击 HTML 文件——file://下所有src都会被 Android Chrome / iOS Safari 拒绝 - 检查 Network 面板，确认每个
source的响应状态码和 Content-Type 是否正常 - 想捕获加载失败，得手动监听每个
source的父audio的error事件，再用 JS 切换src或提示用户
preload="metadata" 是不是比 auto 更靠谱
是。preload="auto" 会让浏览器预加载整个音频，对大文件（比如 10MB 的背景音乐）直接拖慢首屏，还可能被移动端系统 kill 掉连接；而 preload="metadata" 只拉头部信息（时长、采样率等），足够渲染进度条、判断是否可播，又不占带宽。
尤其当用了多 source 回退时，preload="metadata" 还能帮浏览器更快排除不支持的格式——它会先 fetch 各个 source 的 header，根据 type 和响应头快速决策，而不是盲目下载整文件。
- 不要依赖
preload来“保证播放”，它只是提示，浏览器可无视 - 如果音频用于关键交互（如点击按钮后立刻播放音效），建议设
preload="auto"并配合loadeddata事件做就绪判断 - iOS Safari 对
preload行为更保守，有时即使设了auto也只下几 KB 就停，实测为准
JS 动态切换 source 时容易踩的坑
用 JS 改 audio.src 或清空再 append source 元素，看似灵活，但实际会重置整个媒体元素状态：已加载的缓冲清空、播放位置归零、paused 变成 true，甚至触发额外的 loadstart 和 emptied 事件。
更稳的做法是：只改一个 source 的 src，然后调 audio.load()，而不是反复删 DOM。
- 改完
src后必须显式调audio.load()，否则浏览器可能继续用旧缓存或旧解码器 - 调
play()前要等canplay或loadeddata事件，不能靠 setTimeout 猜时机 - iOS Safari 在未触发用户手势前，对任何
load()后的play()都会 Promise reject，错误信息是"The request is not allowed by the user agent or the platform in the current context."
