必须同时提供 src 和 controls 属性，并用<source>标签声明 .mp3 与 .ogg 双格式及正确 type 值，否则 Firefox 等浏览器因不支持 MP3 或缺少 MIME 类型而静默失败。
必须带 src 和 controls，且至少提供 .mp3 与 .ogg 双格式 <source>，否则在 Firefox 或部分旧版 Edge 上直接不播放。
为什么只写 <audio src="song.mp3"></audio> 不行
这种写法看似简洁，但实际会失败：Firefox 默认不支持 audio/mpeg（即 MP3），<audio> 没有 controls 就不渲染界面，用户点不了；没 <source> 多格式兜底，浏览器遇到不支持的格式就停在那里，连错误提示都不给。
常见现象包括：
- 控制条显示为空白或“加载中”，Network 面板里音频请求状态是 200 但
Content-Type是text/plain（服务器没配 MIME 类型） - Chrome 控制台报
DOMException: The element has no supported sources - 双击 HTML 文件本地打开时，路径为
file:///协议，Chrome/Firefox 直接拒绝加载音频资源
<source> 的 type 属性不能省、不能写错
type 是浏览器判断能否解码的关键依据。不写 type，Safari 可能跳过该 <source>；写错（比如 audio/mp3）等于无效声明。
立即学习“前端免费学习笔记（深入）”；
正确写法只有这些：
-
type="audio/mpeg"对应.mp3文件 -
type="audio/ogg"对应.ogg（Vorbis 编码）或.oga -
type="audio/wav"对应.wav，但体积大、不推荐用于常规音频
示例结构：
<audio controls preload="metadata"> <source src="./audio/intro.mp3" type="audio/mpeg"> <source src="./audio/intro.ogg" type="audio/ogg"> 您的浏览器不支持 audio 元素。 </audio>
开发阶段路径与服务必须匹配
路径写错是 404 最常见原因，但更隐蔽的问题出在服务端配置：
-
src必须是相对路径（如"./audio/song.mp3"）或绝对 URL（如"https://cdn.example.com/song.ogg"），不能是"C:\music\song.mp3"或"file:///xxx" - 用
python -m http.server启服务时，它默认不返回正确的Content-Type，MP3 会变成text/plain，导致 Safari/Edge 拒绝加载 - GitHub Pages、Vercel 等平台自动识别常见格式，但自建 Nginx/Apache 需手动添加 MIME 类型映射
验证方法：打开浏览器 Network 面板，点击音频请求，确认 Response Headers 中有 Content-Type: audio/mpeg 或 audio/ogg。
移动端和自动播放的硬约束
加了 autoplay 也不代表能响——现代浏览器强制要求“有声自动播放”必须满足两个条件：已存在用户手势 + muted 为 true。iOS Safari 更苛刻：首次调用 play() 若未静音，大概率被拒。
所以规范写法中不建议加 autoplay，除非你明确需要静音开场并后续再开声：
- 若真要自动播放，必须同时写
autoplay muted - JS 控制时，
play()必须在click或touchstart回调里调用，并处理 Promise 拒绝 -
preload="metadata"建议显式加上，避免首次play()因元数据未加载而失败
真正容易被忽略的是：即使所有代码都对，只要音频文件本身采样率异常（如 32000Hz）、编码非标准（如 MP3 使用了罕见 profile），某些 Android WebView 仍会静默失败，无任何控制台提示——这时得换编码工具重导一次。
