preload 是浏览器预加载提示而非强制指令，其实际行为受dom状态、设备模式、响应头、标签属性及浏览器差异等多重因素影响，需结合link预加载和js干预确保关键资源及时加载。
preload 不是开关，是提示——浏览器听不听、听多少、什么时候听，它说了不算。
preload="auto" 为什么没发起请求？
这不是代码写错了，而是浏览器主动降级或跳过预加载。常见真实原因：
- 页面刚加载完、
audio元素还没插入 DOM（比如还在 DocumentFragment 里），preload不触发任何加载 -
src是 JS 后续动态赋值的，此时preload已错过初始化时机 - 用户设备开启了 Low Data Mode（iOS）或省电模式（Chrome/Edge），浏览器直接按
metadata处理 - 标签页未获得焦点（比如后台打开），Chrome/Edge 会延迟加载直到 tab 激活
- 服务端响应头缺失
Content-Length或返回了Accept-Ranges: none，部分浏览器放弃分段预取
metadata 和 none 的实际差异比文档写的更细
metadata 确实只拉元信息（时长、采样率、是否含封面），但 Chrome 在此模式下仍可能悄悄下载前 1–2 KB 数据，用于快速响应首次 play()；none 表面“不加载”，实则更像“懒加载触发器”——点击播放时才开始拉流，且首次播放延迟明显。
- 长音频（>5MB）、弱网场景优先用
metadata：控件进度条可显示，首屏无带宽压力 -
none适合一次性提示音、低频交互音效，但要注意：iOS Safari 对none也常预取少量数据，无法完全规避 - 设成
none后再 JS 改成auto，不会重加载——必须配合load()或重新赋值src
preload 和 autoplay、controls 的隐式优先级关系
autoplay 存在时，桌面浏览器基本无视 preload 值，直接开始加载；但 iOS Safari 禁止自动播放音频，此时 preload="auto" 形同虚设，等效 metadata。
- 有
controls属性时，浏览器倾向加载metadata（哪怕设为auto），因为 UI 需要显示时长和拖拽条 - JS 调用
load()会强制走完整加载流程，覆盖当前preload状态；但如果已触发过loadedmetadata，再次调用无效 -
preload是初始提示，后续修改属性值（如从none→auto）不触发新请求
真正想预加载，光写 preload="auto" 远不够
强依赖快速就绪（比如游戏音效、实时语音反馈）时，必须组合干预：
- 确保
audio元素已挂载到 DOM（display: none可接受，但不能是未插入状态） - 手动设置
preload="none"→ 赋值src→ 立即调用load()→ 监听canplaythrough - 对关键资源，额外加
<link rel="preload" href="xxx.mp3" as="audio">，绕过audio标签自身的限制 - 检查服务端是否返回
Accept-Ranges: bytes和Content-Length，否则分片预取可能失败
最易被忽略的一点：preload 的效果高度依赖浏览器实现细节和运行时上下文，同一段代码在 Chrome Desktop、Safari iOS、Edge Mobile 上行为可能完全不同——别只测一个环境。
