preload="none"是最省流量的设置，浏览器完全不预加载音频数据，仅在用户点击播放时才请求；metadata仅加载几KB元信息，适合需显示控件的场景；auto应避免使用。
preload="none" 是最省流量的设置
浏览器默认对 <audio> 元素的 preload 行为并不统一，尤其在移动网络下容易悄悄下载大量音频数据。设为 none 后，浏览器不会预加载任何音频数据，直到用户主动点击播放才开始请求，这是节省流量最直接有效的方式。
-
preload="none"：完全不预加载，适合内容多、用户跳过率高、或明确按需播放的场景（如播客列表、语音评论） -
preload="metadata"：只拉取时长、码率、封面等元信息，体积通常几 KB，适合需要显示播放器控件但不想载音频本体的情况 -
preload="auto"：由浏览器决定，实际中多数会尝试下载前几秒甚至整个文件，极易浪费流量，应避免在非自动播放场景使用
注意：即使设了 none，某些浏览器（如 Safari iOS）在 autoplay 被禁用前提下仍可能触发部分预加载，但不会下载完整资源。
配合 controls 属性时 metadata 有时更合理
如果页面必须显示播放器控件（比如有 controls 属性），且希望进度条能正确显示总时长、拖动响应及时，preload="metadata" 是折中选择。
- 播放器 UI 渲染依赖元信息，若用
none，Chrome 和 Firefox 会显示“未知时长”，拖动条不可用，用户体验打折扣 -
metadata请求体积小，一般不超过 10 KB，对流量影响极小 - 不要以为加了
controls就必须用auto——那是常见误解，auto完全没必要
示例写法：
<audio controls preload="metadata" src="talk.mp3"></audio>
立即学习“前端免费学习笔记（深入）”；
动态设置 preload 在 JS 中无效
试图用 JS 修改 preload 属性（比如 audioEl.preload = 'none'）不会改变已发起的请求行为。一旦元素插入 DOM 或属性被解析，浏览器就已根据当时值做了决策。
- preload 是 HTML 解析阶段生效的静态提示，不是运行时可干预的加载策略
- 若需精细控制加载时机，应延迟创建
<audio>元素，或用 JS 动态设置src（此时 preload 才真正起作用） - 错误做法：
const el = document.querySelector('audio'); el.preload = 'none'; // 无用 - 正确做法：
const el = document.createElement('audio'); el.preload = 'none'; el.src = 'file.mp3'; // 此时有效
移动端特别要注意 autoplay 和 preload 的组合陷阱
iOS Safari 和 Android Chrome 对 autoplay 限制严格，但它们对 preload="auto" 的处理却很激进——哪怕没 autoplay，也可能提前缓存几十 MB。
- 即使写了
autoplay="false"，只要preload="auto"，iOS 上仍可能预加载 - 微信内置浏览器曾因
preload="auto"导致 H5 页面加载缓慢、用户投诉流量超标 - 真正安全的组合是：
preload="none"+ 显式调用play()（在用户手势后）
别依赖“反正不自动播就不会加载”——preload 的语义就是“准备加载”，跟是否 autoplay 无关。
有些音频 URL 带 query 参数（如 ?t=123），不同参数会被当作不同资源，preload="metadata" 可能触发多次小请求，这种细节容易漏掉。
