移动端audio加载延迟主因是加载策略与弱网/低端机/微信WebView不匹配；应设preload="metadata"仅加载头部信息，避免阻塞首屏。
移动端网页中 audio 加载延迟，本质不是“音频本身慢”，而是加载策略、资源调度和浏览器限制没对齐移动端真实环境。尤其在 4G 弱网、低端安卓机、微信 WebView 等场景下，一个未优化的 <audio></audio> 标签可能让首屏核心内容（比如课程提示音、语音引导）卡顿 2–3 秒才响起，直接影响用户感知和业务转化。
优先用 preload="metadata" + 显式控制加载时机
默认 preload 行为在不同 WebView 差异极大：iOS Safari 可能忽略，微信 Android WebView 可能直接预加载全部音频导致阻塞首屏。我们实测发现，设为 preload="metadata" 是最稳妥的起点——它只拉取时长、码率、编码格式等头部信息（通常 play()。
- 不要写
preload="auto"，移动端几乎从不真正“自动”且易引发资源争抢 - 若音频是关键引导音（如“点击开始上课”），建议在页面 DOM 就绪后、用户交互前主动触发
audio.load()，把解码准备提前到空闲期 - 避免在
DOMContentLoaded里立刻play()，此时 metadata 可能未就绪，会静默失败
音频资源本身要轻量+格式精准
体积和编码格式是硬门槛。企鹅辅导项目把一段 8 秒引导音从 1.2MB MP3 压到 196KB Opus 后，FCP 提前了 320ms，LCP 下降 410ms。Opus 在 32–64kbps 下音质足够语音场景，体积比同等质量 MP3 小 40%–60%，且被所有现代移动端浏览器原生支持。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 语音类音频统一转 Opus（.opus），采样率 16kHz，单声道，码率 48kbps 足够清晰
- 禁用 MP3 的 ID3v2 标签（尤其是封面图），它们会拖慢 metadata 解析
- 避免使用
<source></source>多格式兜底——每个source都会触发一次 HTTP 请求试探，增加首屏请求数
绕过自动播放限制，但别硬刚策略
移动端浏览器（尤其 iOS Safari 和微信）要求音频必须由用户手势触发才能播放。强行在页面加载完就 play() 会抛 DOMException，且后续再调用也大概率失效。这不是 bug，是策略。
- 把音频实例化放在首次用户交互（如点击、触摸）回调里，而不是全局创建
- 若需“伪自动播放”（比如用户点开页面后 0.5 秒内响铃），可用
AudioContext播放极短合成音（play() 真实 audio 就不会被拒 - 微信 WebView 中，可配合
WeixinJSBridgeReady事件做一次安全兜底，但不可依赖
CDN 与缓存策略必须匹配音频特性
音频文件不像 JS/CSS 那样需要强一致性，但它对边缘节点覆盖极度敏感。我们曾发现 Lighthouse 测出 1.2s 加载，但真实用户中位数达 2.7s，根因是 CDN 未在三四线城市部署音频专用节点，请求被迫回源。
- 音频资源单独走一套 CDN 域名，配置
Cache-Control: public, max-age=31536000（一年），并开启 Brotli 压缩 - 利用 Service Worker 缓存关键音频（如欢迎音、错误提示音），首次加载后，后续访问可秒开
- 避免把音频和主包一起打包进 JS bundle —— 它无法被浏览器独立缓存，更新 JS 就连带清掉音频缓存
