必须带controls属性并提供MP3+OGG双源，否则Firefox/Safari/移动端大概率无声；只写src和autoplay会失效，因现代浏览器默认拦截有声自动播放，需autoplay+muted组合并由用户手势触发play()，且type属性必须正确（audio/mpeg、audio/ogg）并匹配服务端MIME。
必须带 controls 属性，且至少提供 MP3 + OGG 双格式 <source></source>，否则在 Firefox、Safari 或移动端大概率无声或不播。
为什么只写 src 和 autoplay 会失效
现代浏览器（Chrome 94+、Safari、Edge）默认拦截有声自动播放。即使写了 autoplay，只要没加 muted，play() 调用会直接被拒绝，控制台可能只报 NotAllowedError，不显眼但致命。
-
autoplay+muted是唯一能绕过初始拦截的组合；后续再设audio.muted = false才可能恢复声音（iOS 尤其依赖这步） - 仅靠
autoplay想“页面一开就响”，在绝大多数真实用户环境里等于没写 - 开发时用
python -m http.server启服务，别双击 HTML ——file://协议下 Chrome/Firefox 会直接拒载音频
<source></source> 的 type 属性不能省也不能写错
浏览器靠 type 值快速跳过不支持的格式。漏写或写成 audio/mp3 这类错误值，会导致该 <source></source> 被完全忽略，哪怕文件本身完全合法。
- MP3 必须写
type="audio/mpeg"（不是audio/mp3） - OGG（Vorbis）必须写
type="audio/ogg"（不是audio/ogv） - WAV 写
type="audio/wav"，但体积大，仅适合短提示音 - 顺序很重要：把兼容性最广的放前面，推荐
MP3 → OGG组合，覆盖 99% 主流环境
路径和服务器响应头必须匹配
本地测试时常见“控制条出来但点不动”，八成是路径或 MIME 类型问题。Network 面板里看音频请求的 Status 和 Content-Type 比对着 HTML 写法更管用。
立即学习“前端免费学习笔记（深入）”；
-
src值必须是相对路径（如"./audio/sound.mp3"）或绝对 URL，不能是C:\xxx\sound.mp3 - Python 自带的
http.server不返回正确Content-Type，MP3 会返回text/plain，导致加载失败 - GitHub Pages 默认配好了常见类型，适合静态部署；自己搭服务需手动配置
audio/mpeg等 header - 大小写敏感：Linux 服务器上
Sound.mp3和sound.mp3是两个文件
JS 控制播放前必须处理 Promise 拒绝
用 audio.play() 触发播放时，它返回一个 Promise。现代浏览器策略下，这个 Promise 很容易被 reject，不捕获就会静默失败。
- 必须写
audio.play().catch(e => console.warn("Play failed:", e)) - 只能在用户真实交互事件中调用（如
click、touchstart），setTimeout模拟点击无效 - 首次播放建议先带
muted，成功后再解静音，iOS Safari 对此非常敏感 - 多个
<audio></audio>共存时，别共用一个Audio实例，每个应独立管理状态
最容易被忽略的是服务器返回的 Content-Type 响应头——它和 HTML 里写的 type 属性要一致，且服务端必须真正发出这个 header，光写对标签没用。
