小众格式（如FLAC、AIFF、MP4A）在HTML中大概率不播，因浏览器是否支持取决于内置解码器及系统媒体框架授权，而非流行度；Safari不支持audio/flac，AIFF被其跳过，MP4A在部分Android WebView中因缺少MediaCodec报错，且均不抛错误、duration为NaN。
为什么小众格式（如 FLAC、AIFF、MP4A）在 HTML 中大概率不播
浏览器对音频格式的支持不是按“是否流行”决定的，而是看解码器是否内置、是否被系统媒体框架授权。FLAC 虽然是无损开源格式，但 Safari（包括 iOS）至今不支持 audio/flac；AIFF 在 Chrome 和 Firefox 中能加载，但 Safari 会直接跳过 <source></source>；MP4A（即 AAC 封装在 MP4 容器中）需 type="audio/mp4"，但部分 Android WebView 会因缺少 MediaCodec 报 NotSupportedError。这些失败都**不抛错误、不触发 error 事件、duration 为 NaN**，看起来就像“没写 audio 标签”。
用 Web Audio API 解包并重喂给 AudioContext 是唯一可靠路径
当原生 <audio></audio> 对某个格式束手无策时，得绕过它——用 fetch() 拿到 ArrayBuffer，用 AudioContext.decodeAudioData() 解码成 PCM，再用 AudioBufferSourceNode 播放。这招对 FLAC、AIFF、WAV-IEEE Float、甚至自定义编码（如 Opus in Ogg with custom header）都有效。
- 必须先调用
audioContext.resume()，否则 iOS/Safari 会挂起上下文，decodeAudioData()直接 reject - 解码后不能反复调用
start()同一个AudioBufferSourceNode，需每次新建节点 - 小文件（
- 示例关键链路：
fetch('sound.flac').then(r => r.arrayBuffer()).then(buf => ctx.decodeAudioData(buf))
服务端转码 + 前端 fallback 切换比硬扛更工程友好
纯前端解码适合短提示音（≤3s），背景音乐或长音频仍推荐服务端兜底。真实项目里更稳的做法是：上传时自动转出 MP3 + OPUS + WAV 三份，前端用 <audio></audio> 按顺序 fallback，只把小众格式当作“开发态调试标识”，不参与生产交付链路。
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- MP3 放第一：
<source src="a.mp3" type="audio/mpeg"></source>（注意不是audio/mp3） - OPUS 放第二：
<source src="a.opus" type="audio/opus"></source>（Chrome/Firefox 体积小、质量高） - WAV 放最后：
<source src="a.wav" type="audio/wav"></source>（仅限 ≤1s 提示音，Safari 兼容最稳） - 别用 OGG Vorbis 当主力——Firefox/Chrome 可播，但 Safari 完全无视，放最后等于白写
容易被忽略的 MIME 和响应头陷阱
即使你把 FLAC 文件丢进 <source></source> 并写了 type="audio/flac"，如果服务器返回的 Content-Type 是 text/plain 或空，浏览器连解码器都不会唤起。这不是前端能改的，必须配服务端。
立即学习“前端免费学习笔记（深入）”；
- Apache：
AddType audio/flac .flac加到.htaccess或虚拟主机配置 - Nginx：
types { audio/flac flac; }补在http块内 - 本地开发别双击 HTML——
file://协议下 Chrome/Firefox 禁音频加载，必须用python3 -m http.server - 验证方式：Network 面板看响应头，确认
Content-Type: audio/flac准确存在
真正麻烦的从来不是“怎么让 FLAC 播出来”，而是“怎么让用户感知不到它不是原生播放”。Web Audio API 的解码延迟、内存占用、iOS 上下文挂起、服务端转码队列积压……这些细节堆起来，才决定小众格式到底能不能进生产环境。
