preload属性仅是浏览器加载建议而非强制指令，其none、metadata、auto三值实际行为差异大：none仍可能取首帧，metadata依赖Range支持，auto在iOS Safari中恒为none；真正有效需结合服务端faststart、link preload及JS load()调用。

preload 属性不能强制浏览器预加载视频，它只是向浏览器“建议”加载策略，实际行为由浏览器自主决定（尤其在移动设备上常被忽略）。

preload 可选值及真实行为差异

该属性有三个合法值：none、metadata、auto，但它们的生效逻辑并不对称：

• none：明确告诉浏览器“不要加载任何数据”，包括封面图和时长等元信息——多数现代浏览器仍会请求首帧或 Content-Range 头来获取尺寸/格式，但不会下载完整元数据
• metadata：仅请求视频容器头部（如 MP4 的 moov box），用于获取时长、宽高、编码格式；若服务器不支持字节范围请求（Accept-Ranges: bytes），此值可能退化为加载整个文件前几 KB
• auto：最模糊的选项——浏览器可完全忽略它；Chrome 桌面版通常按 metadata 处理，iOS Safari 则一律当作 none（无论声明为何）

为什么设置了 preload="auto" 视频还是不预加载？

这不是代码写错了，而是受以下现实约束影响：

• 移动端 Safari（所有 iOS/iPadOS 版本）强制禁用自动预加载，preload 值会被静默覆盖为 none
• 用户开启了“低电量模式”或“节省流量”设置，Chrome/Firefox 会主动降级为 metadata 或跳过缓冲
• 视频资源未开启 HTTP Range 请求支持，导致 metadata 模式下必须下载整个文件才能解析时长
• preload 仅作用于页面初始加载阶段；动态插入的 元素即使设了该属性，也不会触发预加载

比 preload 更可控的预加载手段

若目标是提升首帧显示速度，应组合使用更底层的控制方式：

• 服务端确保响应头含 Accept-Ranges: bytes，并把 moov box 移到文件开头（可用 ffmpeg -c copy -movflags +faststart 修复）
• 用 主动发起预加载请求（注意：仅对同域资源有效，且不触发解码）
• 对关键视频，在 JS 中提前创建 Video 实例并调用 load() 方法（需处理 canplay 事件避免重复加载）

真正起效的不是 preload 属性本身，而是它配合服务端配置、网络环境与播放时机共同作用的结果。单独调高这个值，解决不了卡顿问题。