audio标签preload属性仅为弱提示，实际加载由浏览器策略等决定；合法值为none、metadata、auto，其中metadata最稳妥，需服务端支持Accept-Ranges；可靠预加载须结合JS控制、DOM挂载与响应头优化。
audio 标签的 preload 属性不是加载开关，而是向浏览器发出的弱提示，实际是否加载、加载多少，取决于浏览器策略、设备环境、网络状态和服务端配置。想靠它“保证预加载”，必须配合 DOM 状态、JS 控制和响应头优化。
preload 的三个值怎么选才靠谱
合法值只有 none、metadata、auto，其他写法（如 "true" 或空字符串）等同于 none：
- preload="none"：建议跳过预加载。但 Chrome 等仍可能拉前几 KB 做快速响应准备，不等于“零请求”
- preload="metadata"：只请求音频头部（时长、采样率、封面等），不下载音频帧。最稳妥，省流量、支持进度条，但依赖服务端返回 Accept-Ranges: bytes
- preload="auto"：桌面浏览器常降级为 metadata；iOS Safari 直接忽略，等同于 none；微信 X5 内核也基本不认
为什么写了 preload 却没看到网络请求
这不是代码写错了，是浏览器主动抑制了行为。常见原因包括：
- audio 元素还没插入 DOM（比如还在 DocumentFragment 中，或父容器 display: none 且未挂载）
- src 是 JS 后续动态设置的——preload 只在 HTML 初始解析阶段生效
- 设备开启了低电量模式或“省流量”设置，Chrome/Safari 会强制降级为 metadata 或跳过
- 服务端响应头缺失 Accept-Ranges: bytes，导致 metadata 模式无法分段取 moov，部分浏览器直接放弃
- 同时设置了 autoplay，桌面浏览器可能绕过 preload 直接加载；但 iOS Safari 禁止自动播放，此时 preload="auto" 也无效
真正要预加载，得用 JS 主动控制
仅靠 HTML 属性不可靠，关键操作在 JS 层：
立即学习“前端免费学习笔记（深入）”；
- 确保 audio 已挂载到 document.body 下（visibility: hidden 或 position: absolute 都可以）
- 先设 preload="none"，再赋值 src，然后立即调用 .load() 触发完整加载
- 监听 canplaythrough 事件（表示缓冲足够播完），比 loadeddata 更适合判断“就绪”
- 若已进入 loadedmetadata 状态，再次 .load() 不会重发请求；需先清空 src 再重设
- 动态改 preload 值（如从 none 改 auto）不会触发重加载，必须配合 .load() 或重设 src
更可控的补充手段
单靠 preload 属性很难稳定提效，建议组合使用：
- 用 <link rel="preload" as="audio" href="sound.mp3"> 提前发起 fetch 请求（仅同域有效，不触发解码）
- 服务端确保音频文件支持字节范围请求（Nginx 需开启 add_header Accept-Ranges bytes;）
- MP3 文件无需 faststart，但 MP4/AAC 容器建议用 ffmpeg 加 -movflags +faststart 把元数据放开头
- 在微信等 WebView 中，优先延迟创建 audio 实例（用户点击后再 new Audio(src)），并主动 .load()
