MP3是当前最稳妥的默认音频格式，因主流浏览器原生支持且在音质、体积与解码效率间平衡；WAV体积过大，Ogg在Safari中不支持；需显式声明type="audio/mpeg"并避免ID3v2.4标签。
MP3 是当前最稳妥的默认选择
绝大多数现代浏览器（Chrome、Firefox、Safari、Edge）原生支持 MP3，且它在音质、体积、解码效率之间取得了实际可用的平衡。WAV 虽无损，但文件体积通常是同内容 MP3 的 5–10 倍，加载慢、易触发浏览器 preload 中断；Ogg（.ogg/.oga）在 Firefox 和 Chrome 上支持良好，但在 Safari（尤其是 iOS）中完全不识别，直接静音失败。
若只用单个 <source></source>，优先写 type="audio/mpeg" 并指向 MP3 文件。不要依赖 “浏览器自动选” —— 实际上，一旦第一个 <source></source> 被识别且可加载，后续 source 就被跳过，哪怕它格式更优。
- MP3 推荐编码参数：
bitrate=128kbps（语音类可压到64kbps），sampleRate=44100Hz，CBR 或 VBR 均可 - 避免使用 ID3v2.4 标签，部分旧版 WebView（如 Android 7–9 系统内置浏览器）会因解析失败而静默拒播
- 不要用 LAME 的
--preset insane，它生成的帧头结构可能被某些安卓厂商定制内核拒绝
需要更高音质时，用 MP3 + Web Audio API 动态补偿
纯 HTML <audio></audio> 标签无法做实时均衡或动态范围压缩。如果设计要求“听感更饱满”，不要指望换 WAV 或 FLAC —— 它们在 Safari 和多数安卓 WebView 中根本播不了。可行路径是：仍用 MP3 作为源，通过 AudioContext 加载后走 Web Audio 处理链。
例如用 convolverNode 加载房间脉冲响应做轻量混响，或用 gainNode + scriptProcessorNode（或现代 AudioWorklet）做自适应低频提升。关键点在于：音频必须由用户手势触发首次播放后，AudioContext 才能脱离 suspended 状态 —— 否则 decodeAudioData 会静默失败，控制台也不报错。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- MP3 文件需为“可流式解码”格式：禁用
VBRI头，启用Xing头（LAME 默认开启） - 避免在
fetch()后直接传 blob 给decodeAudioData()：先用arrayBuffer，否则 iOS Safari 可能卡在 promise pending - Web Audio 处理链一旦建立，就别反复创建
AudioContext—— 它开销大，且移动端容易触发内存回收导致播放中断
移动端 WebView 兼容性比桌面更苛刻
微信、QQ、钉钉、飞书等主流 App 内置 WebView，底层可能是 X5（腾讯）、QuickJS（字节）、或定制 Chromium。它们对 <audio></audio> 的 autoplay 政策比桌面更严，且对音频格式支持不一致：X5 内核明确不支持 Ogg；部分飞书旧版 WebView 会忽略 preload="auto"，只认 preload="metadata"；而安卓厂商系统 WebView（如华为 EMUI 内置）甚至会拦截 type="audio/mp3"，只接受 type="audio/mpeg" —— 少一个字母就失效。
真实工程建议：服务端根据 UA 判断客户端类型，动态返回不同 <source></source> 顺序。例如对微信 UA，把 MP3 放第一位并显式声明 type="audio/mpeg"；对桌面 Chrome，则可把 Ogg 放前位用于节省带宽。
- 不要依赖
canPlayType()返回"probably"：安卓很多 WebView 返回空字符串或"maybe"，但实际能播 - 在 iOS WKWebView 中，即使加了
webkit-playsinline和muted，MP3 仍可能因未绑定用户手势而被拦截 —— 必须调一次play().catch(...)并捕获NotAllowedError来兜底 - 所有音频文件建议放在同域 CDN，避免跨域导致
AudioContext.decodeAudioData拒绝解析
preload="metadata" 是兼顾加载与兼容的折中点
preload="auto" 在移动端常被浏览器无视，尤其在 3G/4G 弱网下会被强制降级为 metadata；而 preload="none" 虽省流量，但用户点击播放按钮后要等待完整加载，体验断层。真正可控、广泛支持的是 preload="metadata"：它只拉取音频头信息（时长、采样率、是否循环），体积小（通常
注意：当同时设置 autoplay 时，preload 会被忽略 —— 这是规范行为，不是 bug。所以如果你需要“静音预加载+手势后播放”，必须显式移除 autoplay，改用 JS 控制。
- MP3 的 metadata 请求实际是发一个
Range: bytes=0-2047的 HEAD 请求，服务端需正确响应206 Partial Content - 某些 Nginx 配置会错误地将 MP3 的
Content-Type设为audio/x-mpeg，应统一设为audio/mpeg - 若用
<link rel="preload" as="audio">，务必加上type="audio/mpeg"，否则 Safari 会直接跳过预加载
preload="metadata" 控节奏。最容易被忽略的是——你以为在调格式，其实浏览器早就在策略层做了裁决；你看到的“没声音”，八成不是代码写错了，是播放时机没卡准用户手势的那 300ms 窗口。 
