preload="metadata"仅请求视频开头的moov box（几kb），获取时长、宽高、编码格式、音轨数及封面帧等元数据，不加载音视频帧；但需服务端返回accept-ranges: bytes且文件经ffmpeg -movflags +faststart优化，否则可能退化为全量下载。
preload="metadata" 实际加载什么内容
它只请求视频文件开头的容器元数据（moov box），包括时长、宽高、编码格式、音轨/字幕轨道列表、封面帧（如果有）等，不下载任何视频帧或音频帧。这部分数据通常只有几 KB，100–300ms 内就能完成请求和解析。
但这个行为有个硬前提：Accept-Ranges: bytes 响应头必须存在，且视频文件本身已用 ffmpeg -c copy -movflags +faststart 重写过——否则 moov box 在文件末尾，浏览器不得不下载整个文件才能拿到时长。
为什么有时设了 metadata 却还是加载了大量数据
常见原因有这些：
- 服务端没返回
Accept-Ranges: bytes，浏览器 fallback 成顺序读取，直到读到 moov 才停，可能已下几百 KB 甚至更多 - 视频没做
faststart优化，moov 在文件末尾，浏览器无法“只取头”，只能一路下载到底 - 某些旧版 Android 浏览器或 WebView 对
preload="metadata"支持不完整，会静默降级为auto - 开发者误加了
autoplay但没配muted，触发播放失败后浏览器重试策略导致额外请求
如何验证 preload="metadata" 是否真的只加载了元数据
打开 Chrome DevTools → Network 面板，过滤 media 或直接找视频 URL，点开请求详情看：
- Response Headers 里是否有
Content-Range字段（如bytes 0-1023/12345678）？有则说明是范围请求，大概率只取了开头 - Size 列显示的传输体积是否在 1–5 KB 区间？超过 10 KB 就值得怀疑
- Preview 或 Response 标签页里能否看到可读的字符串如
moov、mvhd、tkhd？这是 MP4 元数据块的典型标识
移动端 iOS Safari 的特殊表现
iOS Safari 完全无视 preload="auto"，但对 metadata 是认真的——不过它有个隐藏限制：如果视频未标记 muted 且带 autoplay，即使 preload 设对了，也可能因权限拒绝而中断加载流程，导致 loadedmetadata 事件迟迟不触发。
所以实际部署时，这两项必须一起出现：preload="metadata" 和 muted。少一个，就可能让“只加载元数据”变成“加载零数据”或者“加载全部数据”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
