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 的moovbox），用于获取时长、宽高、编码格式；若服务器不支持字节范围请求（Accept-Ranges: bytes），此值可能退化为加载整个文件前几 KB -
auto：最模糊的选项——浏览器可完全忽略它；Chrome 桌面版通常按metadata处理，iOS Safari 则一律当作none（无论声明为何）
为什么设置了 preload="auto" 视频还是不预加载？
这不是代码写错了，而是受以下现实约束影响：
- 移动端 Safari（所有 iOS/iPadOS 版本）强制禁用自动预加载，
preload值会被静默覆盖为none - 用户开启了“低电量模式”或“节省流量”设置，Chrome/Firefox 会主动降级为
metadata或跳过缓冲 - 视频资源未开启 HTTP Range 请求支持，导致
metadata模式下必须下载整个文件才能解析时长 -
preload仅作用于页面初始加载阶段；动态插入的<video>元素即使设了该属性，也不会触发预加载
比 preload 更可控的预加载手段
若目标是提升首帧显示速度，应组合使用更底层的控制方式：
立即学习“前端免费学习笔记（深入）”；
- 服务端确保响应头含
Accept-Ranges: bytes，并把moovbox 移到文件开头（可用ffmpeg -c copy -movflags +faststart修复） - 用
<link rel="preload" as="video" href="xxx.mp4">主动发起预加载请求（注意：仅对同域资源有效，且不触发解码） - 对关键视频，在 JS 中提前创建
Video实例并调用load()方法（需处理canplay事件避免重复加载）
<video id="hero-video" preload="metadata" poster="cover.jpg">
<source src="video.mp4" type="video/mp4">
</video>
<script>
const vid = document.getElementById('hero-video');
// 确保 DOM 加载完成后再显式触发加载
if (vid.readyState < 2) vid.load();
</script>
真正起效的不是 preload 属性本身，而是它配合服务端配置、网络环境与播放时机共同作用的结果。单独调高这个值，解决不了卡顿问题。
