HTML音频兼容需确保格式链顺序正确、MIME精准匹配及服务端配置完备：MP3（audio/mpeg）置首，OGG（audio/ogg; codecs=vorbis）次之，WAV兜底；禁用无效type；Nginx须配add_type与CORS；移动端play()必须由非passive用户手势触发。
HTML音频播放器能播出来，不等于真兼容；多数“无声”问题出在格式链断裂、MIME错配或手势缺失，不是代码写错了。
audio标签多格式fallback怎么写才真正生效
浏览器按canPlayType()，第一个返回"probably"的就加载，后续全跳过。顺序写错，高兼容格式根本没机会执行。
- 必须把
type="audio/mpeg"（MP3）放最前——iOS/macOS Safari 必须有它，且只认这个 MIME，audio/mp3是无效写法 - 第二位补
type="audio/ogg; codecs=vorbis"（不是opus）——Firefox/Linux 常依赖此格式，但 Safari 会直接跳过audio/ogg声明，哪怕文件存在 - 短提示音可加
type="audio/wav"兜底——Safari 对 16-bit PCM WAV 支持稳定，比 OGG 更可靠；别用 IEEE Float 编码，Chrome 直接拒解码 - 删掉
type="audio/mp4"或type="audio/ogg; codecs=opus"这类“看起来先进”的写法——老版 Safari 和部分企业内网浏览器会返回空字符串，导致 fallback 链中断
服务端MIME和CORS配置比前端代码更容易被忽略
前端Content-Type不匹配或缺Access-Control-Allow-Origin，音频请求就是静默失败——Network 面板里可能只显示 pending 或 0B 响应，连 error 事件都不触发。
- Nginx 配置必须显式声明：
add_type audio/ogg .ogg;、add_type audio/mpeg .mp3;、add_type audio/wav .wav; - 所有音频路径需加 CORS 响应头：
add_header Access-Control-Allow-Origin *;（生产环境建议精确域名） - 必须支持
Accept-Ranges: bytes——否则 Safari 拖动进度条卡住、无法 seek，GitHub Pages 默认不带这个头 - 本地开发别双击 HTML 文件：Chrome/Firefox 在
file://协议下禁用play()，必须起本地服务器，如python3 -m http.server 8000
移动端自动播放必须绕过“用户手势”硬约束
iOS Safari 和 Android Chrome 都强制要求首次play()必须由用户点击/触摸直接触发，autoplay muted单独存在等于无效。这不是 bug，是策略。
立即学习“前端免费学习笔记（深入）”；
- 所有
play()调用必须包裹在click或touchstart回调里，且 iOS 17+ 要求该监听器不能设为passive: true - 不要在
DOMContentLoaded、load、canplay里调play()——100% 失败，控制台报The play() request was interrupted - 按钮元素必须在视口内、未被
display: none或opacity: 0遮挡，否则即使点过也静音 - 静音自动播放（
muted+autoplay）在桌面浏览器可行，但移动端仍需首次手势；想有声播放，只能等用户第一次交互后再调一次play()并取消muted
preload和controls取舍直接影响首屏体验
preload不是“预加载”，而是“预加载策略提示”，现代浏览器（Chrome 120+、Safari 17+）对auto基本忽略，Lighthouse 会标为性能风险。
- 要用户立刻点播（如播客列表、BGM 开关）→ 必须加
controls，否则没 UI 控制入口 - 背景音乐类 → 可省略
controls，用 JS 拦截 click 后调play()，避免控件干扰设计 - 小音频（preload="metadata"足够，秒出时长、支持拖拽
- 大音频（>2MB）→
preload="none"更稳妥，等用户明确点击再加载，避免空耗流量和阻塞首屏渲染
真正麻烦的从来不是写几行source，而是确认每个type值在目标浏览器里canPlayType()返回"probably"，且服务端响应头Content-Type与之完全一致——差一个分号、多一个空格，都算失败。
