audio标签加载失败时浏览器静默跳过，常见现象为控件显示“暂停”、duration为NaN、canplaythrough不触发；主因是格式不支持、MIME类型错配或网络/协议限制，须检查Network面板状态码与Content-Type是否匹配，并用多source+正确type实现fallback。
audio 标签加载失败时，浏览器不会报错但会静默跳过
常见现象是控件显示“暂停”图标、duration为 NaN、canplaythrough 事件不触发——这不是 JS 写错了，而是音频资源根本没进解码器。原因通常有三类：格式不被支持、MIME 类型错配、或网络/协议限制。别急着改 JS，先确认 Network 面板里音频请求是否返回 200，且响应头 Content-Type 精确匹配 source 的 type 值（比如 audio/mpeg 对应 .mp3）。
必须用多 source + 正确 type 实现格式 fallback
只写一个 src="a.mp3" 就等于放弃兼容性。浏览器按 DOM 顺序尝试每个 <source>，第一个 canPlayType() 返回 "probably" 的才加载。顺序和 type 必须精确：
-
<source src="a.opus" type="audio/ogg; codecs=opus">—— Chrome/Firefox 体积小、解码快，但 iOS Safari 支持不稳定 -
<source src="a.m4a" type="audio/mp4; codecs=aac">—— iOS/macOS 原生首选，务必确认编码是 AAC-LC（ffprobe a.m4a查看） -
<source src="a.mp3" type="audio/mpeg">—— 兼容底线，type="audio/mp3"是无效写法 -
<source src="a.wav" type="audio/wav">—— 仅用于短提示音，Safari 对 16-bit PCM WAV 支持最稳
漏掉 type 或写错（如 audio/x-wav），Firefox 和 Safari 会直接跳过该 source，连请求都不发。
服务端配置不到位，前端写得再全也白搭
即使 source 全写了，如果服务器返回的 Content-Type 是 text/plain 或空着，浏览器就当普通文本扔掉。Nginx 用户必须在 types 块加：
立即学习“前端免费学习笔记（深入）”；
add_type audio/ogg .opus; add_type audio/mp4 .m4a; add_type audio/mpeg .mp3; add_type audio/wav .wav;
Apache 用户在 .htaccess 加：
AddType audio/ogg .opus AddType audio/mp4 .m4a AddType audio/mpeg .mp3 AddType audio/wav .wav
还要确保响应头含 Accept-Ranges: bytes（否则 Safari 拖动进度条卡死）、Access-Control-Allow-Origin（GitHub Pages 默认不带，跨域请求静默失败）。
降级提示不能靠 JS 监听 error 事件
error 事件在很多场景下根本不会触发：iOS Safari 加载失败时 video.error 常为 null；Chrome 在 file:// 协议下直接屏蔽音频加载，连请求都不发。更可靠的方式是主动探测：
- 用
Audio.canPlayType()预检关键格式，返回空字符串就跳过对应source - 监听
stalled和waiting事件持续超 2s，视为加载失败信号 - 最终降级 UI 直接写 HTML：
<p class="audio-fallback">音频暂不可用，<a href="a.mp3">点击下载</a></p>，不依赖 JS 渲染
真正容易被忽略的是本地开发环境：双击打开 HTML 文件走 file:// 协议，Chrome/Firefox 会禁用所有音频加载。必须用 python3 -m http.server 8000 启服务，才能复现真实行为。
