preload 属性是浏览器加载提示而非强制指令，取值 none/metadata/auto 分别对应跳过预加载、仅加载元信息、允许自主决策；实际加载受焦点、省电模式、DOM状态、响应头等影响，强依赖场景需结合 link[preload] 和 load() 主动控制。
preload 属性不是开关，而是一个提示——告诉浏览器“建议怎么加载”，但最终是否加载、加载多少，由浏览器自己决定。它影响的是资源获取时机和带宽使用节奏，不控制播放行为本身。
三个值的真实含义与适用场景
preload 只接受 none、metadata、auto 三种合法值，其他写法（如 "true"、空字符串）等价于 "none"：
- none：建议跳过预加载，适合大音频或低流量场景；但 Chrome 等浏览器仍可能悄悄拉取前几 KB 以加速首次播放响应
- metadata：只加载时长、采样率、封面等元信息，不下载音频帧数据；兼容性好、省流量，控件进度条能正常显示，是多数情况下的稳妥选择
- auto：允许浏览器自主决策；桌面端常预载前几秒甚至整文件（尤其搭配 autoplay），但 iOS Safari 基本无视该值，等同于 metadata
为什么写了 preload="auto" 却没请求？
这不是代码写错了，而是浏览器主动降级或抑制了预加载。常见原因包括：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 页面刚打开、未获得用户焦点（Chrome/Edge 会延迟加载）
- 设备开启省电模式或 iOS 的 Low Data Mode（Safari/Chrome 自动切为 metadata）
- audio 元素尚未插入 DOM，或 src 是 JS 后续动态设置的（preload 不触发初始加载）
- 服务端响应头缺失 Content-Length 或返回 Accept-Ranges: none（部分浏览器放弃分段请求）
和其它属性/脚本的配合要点
preload 不是孤立生效的，实际行为常被其他因素覆盖：
立即学习“前端免费学习笔记（深入）”；
- 设置了 autoplay，大多数桌面浏览器会忽略 preload 值，直接开始加载并尝试播放；但 iOS Safari 禁止自动播放，此时 preload="auto" 也无效
- 存在 controls 属性时，浏览器倾向优先加载 metadata（哪怕设为 auto），因为 UI 需要显示时长和可拖拽进度条
- 用 JS 调用 load() 方法会强制触发完整加载流程，覆盖当前 preload 状态；但若已进入 loadedmetadata 状态，再次调用无效果
- 动态修改 preload 属性（比如从 "none" 改成 "auto"）不会引发重加载，必须配合 load() 或重新赋值 src
真正想预加载？别只靠 preload
如果业务强依赖音频快速就绪（如游戏音效、通知提示音），单靠 preload 不够，需主动干预：
- 确保 audio 元素已挂载到 DOM（display: none 也可，但不能是 document fragment 中未插入的状态）
- 手动设置 preload="none" → 赋值 src → 调用 load() → 监听 canplaythrough（比 loadedmetadata 更可靠，表示缓冲足够连续播放）
- 对带 token 或时间戳的动态 URL，注意服务端缓存策略；推荐用 immutable + 文件哈希名，避免 Cache-Control: no-cache 导致重复加载
- 更优方案：用
<link rel="preload" as="audio" href="xxx.mp3">提前声明高优先级资源，加载时机更可控，且不受 audio 元素状态限制
