preload 属性是加载建议而非强制指令，取值 none、metadata、auto 分别对应跳过预加载、仅加载元信息、由浏览器自主决策；实际加载受设备、网络、省电模式等影响，且常被 autoplay、controls 或 JS 方法覆盖。
preload 属性不是开关，而是一个加载建议——它告诉浏览器“怎么预加载”，但最终是否加载、加载多少，由浏览器根据环境自主决定。实际效果受设备类型、网络状态、省电模式、服务端响应头等多重因素影响，不能当作强制指令依赖。
三个取值的真实含义与适用场景
preload 只接受 none、metadata、auto 三种合法值，其他写法（如 "true" 或空字符串）等价于 "none"：
- none：建议跳过预加载。适合大音频/视频、流量敏感场景或用户大概率不播放的内容；但 Chrome 等浏览器仍可能悄悄拉取前几 KB 用于首帧渲染或格式探测
- metadata：只加载时长、分辨率、编码格式、封面图（poster）等元信息，不下载音视频帧数据；兼容性好、省流量，控件进度条可正常显示，是多数页面的稳妥选择
- auto：允许浏览器自主决策加载量。桌面端常预载前几秒甚至整文件（尤其搭配 autoplay），但 iOS Safari 基本无视该值，一律降级为 metadata 或 none
为什么写了 preload="auto" 却没请求？
这不是代码错误，而是浏览器主动抑制了预加载。常见原因包括：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 页面刚打开、audio/video 元素尚未获得用户焦点（Chrome/Edge 会延迟加载）
- 设备开启省电模式或 iOS 的 Low Data Mode（Safari/Chrome 自动切为 metadata）
- 媒体元素未插入 DOM，或 src 是 JS 后续动态设置的（preload 不触发初始加载）
- 服务端响应头缺失 Content-Length 或返回 Accept-Ranges: none（部分浏览器放弃分段请求，metadata 模式失效）
preload 不是孤立生效的
它的行为常被其他属性或脚本覆盖：
立即学习“前端免费学习笔记（深入）”；
- 设置了 autoplay，大多数桌面浏览器会忽略 preload 值，直接开始加载并尝试播放；但 iOS Safari 禁止自动播放，此时 preload="auto" 也无效
- 存在 controls 属性时，浏览器倾向优先加载 metadata（哪怕设为 auto），因为 UI 需要显示时长和可拖拽进度条
- 用 JS 调用 load() 方法会强制触发完整加载流程，覆盖当前 preload 状态；但若已进入 loadedmetadata 状态，再次调用无效果
- 动态修改 preload 属性（比如从 "none" 改成 "auto"）不会引发重加载，必须配合 load() 或重新赋值 src
真正想预加载？别只靠 preload
若业务强依赖音频/视频快速就绪（如游戏音效、通知提示音、首屏主视觉），单靠 preload 不够，需组合干预：
- 确保 media 元素已挂载到 DOM（display: none 也可，但不能在 document fragment 中未插入）
- 服务端启用字节范围请求（Accept-Ranges: bytes），并将 MP4 的 moov box 移至文件开头（可用 ffmpeg -c copy -movflags +faststart 修复）
- 用 <link rel="preload" as="video" href="xxx.mp4"> 主动发起高优先级预加载（仅同域有效，不触发解码）
- JS 中提前创建实例并调用 load()，监听 canplaythrough 事件判断就绪状态
