HTML中无损音频（WAV/FLAC）音质变差，主因是浏览器支持弱、解码失败后降级转码、移动端无原生支持、HTTP加载卡顿及系统音频通道重采样；真正高保真应选192kbps MP3或Opus双格式回退。
为什么HTML里放无损音频反而音质变差
不是浏览器“压缩”了你的WAV或FLAC，而是它根本没按原样播——多数浏览器对无损格式支持极弱，甚至直接解码失败后 fallback 到内部降质转码。比如 Chrome 遇到 audio/flac 会静默跳过，转而尝试下一个 <source></source>；Safari 根本不认 FLAC，连报错都不给；Firefox 虽支持 FLAC，但若服务器没返回正确的 Content-Type: audio/flac，它就当普通二进制丢弃，再加载时自动重采样成低比特率流。
- WAV 文件体积大、无压缩，HTTP 加载慢，
preload="metadata"只拉头信息，真正播放时网络卡顿导致缓冲不足，听起来像“断续+失真” - FLAC 在移动端（尤其 iOS Safari）基本不可用：iOS WebKit 至今未实现 FLAC 解码器，强制 fallback 可能触发 JS 播放失败或静音
- 即使文件本身无损，
<audio></audio>元素输出受系统音频通道限制：Mac 默认走 Core Audio 重采样，Windows 可能经 WASAPI 或 Kernel Mixer 二次处理，原始 PCM 帧早已变形
真正可用的“高保真”替代方案
别执着于“无损格式”，要的是“用户听到的音质不劣化”。实测下来，合理编码的 MP3 和 Opus 在绝大多数场景下主观听感优于生搬硬套的 WAV/FLAC。
-
MP3：用ffmpeg -i input.wav -c:a libmp3lame -b:a 192k -ar 44100 -ac 2 output.mp3，192kbps VBR 比 CBR 更稳，兼容所有主流浏览器 -
Opus：比 OGG/Vorbis 更高效，Chrome/Firefox/Edge 原生支持，推荐用于语音类内容：ffmpeg -i input.wav -c:a libopus -b:a 64k -vbr on output.opus - 双格式回退必须写
type属性：<source src="talk.mp3" type="audio/mpeg"></source>+<source src="talk.opus" type="audio/opus"></source>，否则浏览器可能跳过 Opus - 避免在
<audio></audio>上设preload="auto"：它不保证加载全量数据，反而容易触发部分解码+中途卡顿，改用preload="metadata"+ 监听canplaythrough再播放更可靠
JS 控制播放时音质突变的隐藏原因
调用 audio.play() 后音量突然变小、发闷，大概率不是音频文件问题，而是 Web Audio API 的上下文状态干扰。特别是你用了 AudioContext 做音量调节或混音时：
- 未在用户交互后创建
AudioContext：iOS 和新版 Chrome 会强制挂起上下文，后续gainNode.gain.value设置无效，声音被压到极低 -
audio元素和AudioContext输出混用：两个独立音频路径叠加，相位抵消或增益冲突，造成高频衰减、声场塌陷 - 忘记关闭旧上下文：反复创建
AudioContext不close()，浏览器可能自动降频处理，导致解码精度下降
移动端特别注意的采样率陷阱
iOS 设备（包括 Safari 和 WKWebView）对非 44.1kHz / 48kHz 的音频极其敏感。哪怕你用 44.100kHz 导出 MP3，只要实际采样率是 44099Hz 或含微小偏差，iOS 就可能拒绝解码，fallback 到静音或杂音。
立即学习“前端免费学习笔记（深入）”；
- FFmpeg 转换时务必显式指定：
-ar 44100（不是-r），并加-acodec copy避免重采样引入误差 - 检查原始文件采样率：
ffprobe -v quiet -show_entries stream=sample_rate -of default=nw=1 input.flac - 不要依赖“导出设置里写了 44.1kHz”——很多 GUI 工具（如 Audacity）默认启用 dither 或 resample filter，实际输出已偏移
最易被忽略的一点：音质问题常出现在“你以为它在播无损，其实它根本没播成功”。先确认 canplaythrough 触发、控制台无 DOMException、地址栏没显示静音图标，再谈音质优化。
