preload 属性不能直接控制流量，它只是向浏览器发出加载建议；真正影响带宽消耗的，是浏览器是否发起请求、请求多少字节，而这由设备、网络策略、服务端响应头和 DOM 状态共同决定。
preload="none" 为什么 still 发起请求？
这不是 bug，而是 Chrome 等桌面浏览器的主动优化：即使设为 none，只要 audio 元素已插入 DOM 且 src 静态存在，浏览器可能悄悄拉取前几 KB（如 ID3 头或 AAC ADTS 帧），只为加速后续 play() 响应。
- 该行为在页面未获得焦点（后台标签页）、启用 Low Data Mode 或服务端返回
Accept-Ranges: none时会被抑制 - iOS Safari 不会这么做——它真·只做字面意思，
none就是不发任何音频数据请求 - 若你观察到 Network 面板有请求但 size 很小（
preload="metadata" 是最省流量的选择吗？
是，但有个硬前提：服务端必须支持字节范围请求（即响应头含 Accept-Ranges: bytes）。否则浏览器为读取时长、码率等信息，可能被迫下载整个文件前几 MB。
- Nginx 默认配置下，MP4/MP3 文件常缺失
Content-Length或Accept-Ranges，导致metadata退化为全量下载 - FFmpeg 转码时没加
-movflags +faststart，moov box 在文件末尾，浏览器无法“只取头部”，只能一路下载到 moov 出现为止 - CDN 缓存了不带
Accept-Ranges的响应，后续所有请求都继承该缺陷，preload彻底失效
动态设置 src 后 preload 不生效怎么办？
preload 只在元素插入 DOM 且 src 已存在时触发初始加载决策。JS 动态赋值 audio.src = 'a.mp3' 后，preload 不会重新评估。
- 必须显式调用
audio.load()才能触发加载流程（注意：仅当当前状态不是loadedmetadata时才有效） - 修改
preload值本身（如从none改为auto）不会触发重加载，必须配合load()或重置src - 如果音频来自 CDN 且未配
crossorigin，某些浏览器会静默失败——连error事件都不触发，看起来就像“没反应”
真正想控流量，别只改 preload 值
单靠 preload 无法达成确定性效果。强依赖场景下，需组合干预：
- 关键音频延迟创建：不要在页面初始化就
new Audio(src)，等用户点击按钮再实例化 - 用
<link rel="preload" as="audio" href="a.mp3">主动 fetch，但它不触发解码，且仅同域有效 - 对极低延迟需求（如提示音），预加载一个 100B 的静音 MP3，比依赖
preload更可控 - 检查 Network 面板中请求是否在
DOMContentLoaded前发出，或监听loadedmetadata后立刻查audio.readyState≥ 2，这才是验证预加载是否生效的唯一方式
容易被忽略的是：哪怕所有配置都对，只要 audio 元素还没插入 DOM，或者用户还没跟页面发生过交互，preload 就等于没写。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
