preload="metadata" 仅在满足三个硬条件时才真正省带宽：服务端返回 Accept-Ranges: bytes、视频经 ffmpeg -movflags +faststart 优化、设置 poster 属性；否则可能下载数 MB 甚至整个文件。
preload="metadata" 在超长视频里确实能省带宽，但省多少、靠什么省、为什么有时还“不省”，得看三个硬条件有没有到位。
为什么 metadata 不等于“只下几 KB”
它本意是只请求 MP4 文件开头的 moov box（通常 2–10 KB），但前提是：
- 服务端响应头必须含
Accept-Ranges: bytes，否则浏览器无法发字节范围请求，可能直接下载前几 MB 甚至整个文件 - 视频文件必须经
ffmpeg -c copy -movflags +faststart重写，把moov移到文件开头；否则浏览器得下完才能找到它 - 若
poster属性缺失，部分浏览器会额外请求首帧（I-frame）来生成封面，这可能多下几百 KB
超长视频下 metadata 的真实带宽消耗
一个 2 小时、4K、5 GB 的 MP4，preload="metadata" 的实际行为取决于上述条件是否满足：
- ✅ 全部满足：仅下载 4–8 KB，耗时
- ❌ 缺
Accept-Ranges：可能下载前 1–5 MB 才能解析出时长（浏览器 fallback 行为） - ❌ 未
faststart：必须下载全部 5 GB 才能拿到元数据——这是最糟情况，比none还浪费
怎么验证你真的只下了 metadata
别信控制台 Network 面板里“Size”列显示的数字，要盯住具体请求：
立即学习“前端免费学习笔记（深入）”；
- 找视频资源的首个
GET请求，点开看Request Headers是否含Range: bytes=0-或类似范围值 - 看
Response Headers是否有Content-Range: bytes 0-7999/5234567890（说明只返回了开头 8 KB） - 如果看到
Status Code: 200且Content-Length接近整个文件大小，说明faststart或Accept-Ranges没生效
超长视频页面的实操建议
对 >30 分钟的视频，preload="metadata" 是底线，但光设属性远远不够：
- 必须用
ffmpeg处理源文件：ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4 - Nginx/Apache 要显式开启字节范围支持（Nginx 默认开，Apache 需确认
mod_headers和Accept-Ranges配置） - 搭配
poster属性，避免浏览器自动生成封面帧 - 监听
loadedmetadata事件再启用播放控件，别依赖video.readyState初始值——它在 metadata 加载完成前常为 0
真正省带宽的不是 preload 这个属性本身，而是它背后那套对视频容器结构和服务端能力的硬约束。漏掉任意一环，超长视频就可能悄悄吃掉用户几十 MB 流量。
