17370845950

HTML5 仅支持特定容器与编码组合：MP3需MPEG-1 Layer III、WAV限16位PCM、OGG仅Opus/Vorbis、M4A/MP4须AAC-LC或ALAC；浏览器兼容性差异大，需用按优先级fallback并精确声明type，且服务端须配置正确Content-Type、CORS及Range支持。

HTML5 支持哪些容器和编码组合

不是所有“.mp3”或“.wav”文件都能在 中播放——浏览器只认特定的「容器 + 编码」组合。比如 .wav 文件若用 FLAC 编码封装，Chrome 仍会报 ERROR: MEDIA_ERR_DECODE；而 .mp3 若是 HE-AAC v2（常见于广播流），Safari 可能静音不报错。

主流支持组合如下（以当前稳定版 Chrome 126 / Firefox 127 / Safari 17.5 为准）：

• .mp3：必须是 MPEG-1 Layer III，采样率 ≤ 48 kHz，CBR 或 VBR 均可；HE-AAC、MP3 Surround 不支持
• .ogg：仅限 opus 编码（推荐）或 vorbis 编码；flac 封装在 .ogg 容器中不被识别
• .wav：仅支持 PCM（16-bit little-endian linear PCM，即标准 CD 格式），不支持 μ-law、a-law、IEEE 754 浮点等变种
• .m4a / .mp4：必须含 AAC-LC（而非 HE-AAC）、ALAC（Apple Lossless）或 MP3 轨道；H.264 音频轨道（如 AAC-HEv2）会被忽略

Chrome、Firefox、Safari 对音频格式的实际兼容差异

三者对 opus 的支持最一致，但落地细节仍有坑：

• Chrome 和 Firefox 默认启用 opus（.ogg 或 .webm 容器），支持 48 kHz 采样率、多声道、动态码率；但 Chrome 120+ 对 opus 的 channel_mapping_family=1（即非标准立体声映射）会静音
• Safari 直到 17.4 才原生支持 opus（此前需转 aac）；且仅接受 .caf 或 .m4a 容器中的 opus，.ogg 仍被拒
• Firefox 对 alac 无支持；Safari 对 vorbis 无支持；Chrome 对 flac 仅支持 .flac 独立容器（不支持 .ogg 封装）

验证方式：在控制台运行

Audio.canPlayType('audio/ogg; codecs="opus"')

的 src 与 多格式 fallback 实操要点

不要只写一个 src 属性，否则 iOS Safari 遇到 .mp3 以外格式大概率失败。正确做法是用 显式声明优先级，并按浏览器实际能力排序：

注意三点：

• 顺序即 fallback 顺序：Safari 会跳过第一个 opus（因不识别 audio/ogg MIME），直接加载 m4a；Chrome 则停在第一个匹配项
• type 属性必须精确：写成 audio/ogg 不够，必须带 codecs 参数；audio/mp4 写成 audio/m4a 无效
• 避免混用容器与编码不匹配的组合，例如 type="audio/ogg; codecs=aac" —— 这在任何浏览器都不会生效

服务端响应头与跨域对音频加载的实际影响

即使格式完全正确， 仍可能卡在 LOADING 或触发 onstalled 事件，常见原因不在前端代码里：

• 缺失 Content-Type 响应头：Nginx 默认对 .opus 返回 application/octet-stream，Chrome 会拒绝解码；需显式配置 types { audio/ogg opus; }
• CORS 限制：当音频来自其他域名且含 crossorigin 属性时，服务端必须返回 Access-Control-Allow-Origin: *；否则 Safari 17+ 会静默失败（无错误日志）
• Range 请求不支持：某些静态文件托管（如早期 GitHub Pages）不支持 206 Partial Content，导致进度条不可拖拽、seek 失败；需确认服务端支持 Accept-Ranges: bytes

用 curl -I https://example.com/audio.mp3 检查响应头是最直接的排查方式。