preload="metadata"是移动网络下最实际的折中选择，它仅加载ID3标签、时长等头部信息而不下载音频帧，但需服务端支持Accept-Ranges和faststart优化，且必须配合load()调用及用户交互才能生效。
preload="metadata" 是移动网络下最实际的折中选择
在 4G/5G 信号波动、用户开启“省流量模式”或使用运营商代理压缩的场景下，preload="none" 看似最省流量，但常导致点击播放后白屏卡顿；preload="auto" 在 iOS Safari 和多数安卓 WebView 中基本被忽略，Chrome for Android 也默认降级为 metadata。真正能稳定生效、且只消耗几 KB 的，只有 preload="metadata" ——它让浏览器拉取 ID3 标签、时长、采样率等头部信息，不加载音频帧数据。
但要注意：这个“几 KB”不是绝对值。如果服务端没返回 Accept-Ranges: bytes，或者 MP3 文件没用 ffmpeg -i in.mp3 -c copy -movflags +faststart out.mp3 优化过（对 MP3 实际是重写 ID3v2 并前置），浏览器可能被迫下载前 1–2 MB 才找到元数据，metadata 就失效了。
动态切换 preload 值必须配合 load() 才生效
你不能只改 audio.preload = "metadata" 就指望浏览器立刻去拉数据。DOM 已存在、src 已设置的前提下，preload 只在元素首次插入时触发一次决策。后续修改属性值不会重加载。
- 正确做法是：先改
preload，再显式调用audio.load() - 如果音频已处于
readyState >= 2（即已有元数据），load()无效果 - 若
src是 JS 动态赋值（如audio.src = "a.mp3"），必须在赋值后立即调用load()，否则preload不起作用 - 注意：调用
load()后会触发loadstart和loadedmetadata事件，这是验证是否真正加载成功的唯一依据
移动端预加载失败的三个隐藏原因
即使写了 preload="metadata"，Network 面板看不到请求，常见于：
-
audio元素还没插入 DOM（比如放在display: none容器里，或未 append 到 document） - 页面尚未获得用户交互焦点（iOS Safari 和 Chrome for Android 要求至少一次 click/touch 后才允许发起媒体资源请求）
- CDN 缓存了不含
Accept-Ranges的响应头，所有下游请求都继承该缺陷；需清 CDN 缓存并确保源站 Nginx 返回Accept-Ranges: bytes和Content-Length
特别容易被忽略的是：Safari 在后台标签页中会完全抑制 preload 请求，哪怕你已经点过页面——它只认当前活跃 tab 的用户意图。
真正控流量，得绕开 preload 属性本身
preload 是提示，不是指令。想确定性节省带宽，得换思路：
- 关键音频延迟实例化：不要在页面初始化就写
<audio src="alert.mp3">，等用户点击按钮再new Audio("alert.mp3") - 用
<link rel="preload" as="audio" href="a.mp3">主动 fetch，但它不触发解码，也不影响audio元素的readyState，仅适合提前进缓存 - 对高频提示音（如消息提醒），预加载一个 120B 的静音 MP3，比依赖
preload更可靠——它体积小、加载快、无兼容性问题
最终效果取决于三件事是否同时满足：元素在 DOM 中、用户有过交互、服务端响应头正确。少一个，preload 就只是 HTML 里一行安静的文本。
