音频体积优化需分层控制：格式选对、编码调准、加载策略改掉。MP3用CBR 128kbps，OGG用Vorbis编码并统一采样率，type属性须写audio/mpeg/audio/ogg，preload设metadata或none，服务器MIME配置必须匹配。
音频体积过大不是靠“压得更狠”解决的，而是要分层控制：格式选对、编码调准、加载策略改掉——三者缺一不可。盲目压缩 MP3 到 64kbps，Safari 可能播不了；只换 OGG，iOS 直接静音；preload="auto" 更是首屏杀手。
MP3 和 OGG 编码参数怎么设才不翻车
MP3 不是越小越好。VBR（可变比特率）在 Firefox/Safari 上容易 decode 失败，必须用 CBR（恒定比特率），推荐 128kbps 起步。用 ffmpeg -i input.wav -acodec libmp3lame -b:a 128k -ar 44100 -ac 2 output.mp3 生成兼容性最稳的版本。
OGG 必须用 Vorbis 编码（不是 Opus），且采样率建议统一为 44100Hz 或 48000Hz。用 ffprobe a.ogg 检查输出里是否含 Audio: vorbis，不含就说明编错了。
- 别用
opus编 OGG：Chrome 支持，但 Safari 完全无视 - 别用
16kHz采样率 MP3：IE9/旧 Edge 会卡住不播 - WAV 坚决不用作 fallback：Chrome 对 IEEE Float WAV 直接拒绝，Firefox 虽支持但体积是 MP3 的 5–10 倍
HTML <source> 标签顺序和 type 属性写法
type 属性写错等于白写。audio/mp3 是无效 MIME 类型，必须写成 audio/mpeg；audio/ogg 才是标准写法，不能写 audio/ogv 或 audio/vorbis。
立即学习“前端免费学习笔记（深入）”；
浏览器按 <source> 从上到下匹配第一个支持的 type，所以顺序就是兼容性排序：
<audio controls> <source src="sound.mp3" type="audio/mpeg"> <source src="sound.ogg" type="audio/ogg"> 您的浏览器不支持音频播放。 </audio>
- MP3 放最前：覆盖 Safari、Chrome、Edge、IE9+
- OGG 紧跟其后：补 Firefox、Opera（iOS 全系不支持，但没关系，它根本不会看到第二行）
- 删掉
<source src="sound.wav" ...>：纯增体积、无实际 fallback 效果
preload 和服务器 MIME 配置才是隐藏瓶颈
preload="auto" 在表格或列表页里是性能毒药——它会让浏览器不管用户要不要听，都把整个音频文件拉下来。首屏 LCP 直接崩盘。正确做法是：preload="metadata"（只取头帧+时长）或干脆 preload="none"，等用户点击再用 JS 触发 load()。
更关键的是服务器响应头：Content-Type 必须匹配 type 值。如果 Nginx/Apache 没配 MIME 映射，返回 text/plain 或空着，浏览器连解码器都不会启动，<audio> 标签形同虚设。
- MP3 文件需返回
Content-Type: audio/mpeg - OGG 文件需返回
Content-Type: audio/ogg - Apache 加
AddType audio/mpeg .mp3；Nginx 加types { audio/mpeg mp3; }
真正卡住体积优化的，往往不是编码器参数，而是没意识到：浏览器只认 MIME 类型 + type 值严格匹配，且 preload 行为受制于用户交互上下文——自动播放策略、后台 tab suspend、甚至 document.hidden 状态都会让预加载失效。这些细节不处理，光调 ffmpeg 参数只是原地打转。
