preload="metadata"仅在服务端支持Accept-Ranges: bytes且视频经faststart优化时才省流量（4–12 KB），否则可能下载50–200 KB甚至整文件；未满足任一条件即成假节省。
preload="metadata" 本身不减少带宽——它只是“请求元数据”的指令，真正省流量的前提是服务端配合。没配好，preload="metadata" 可能反而触发几十 KB 甚至整文件下载。
为什么 metadata 模式有时比 none 还费流量
浏览器想读元数据（时长、宽高、封面帧），必须拿到文件开头的 moov box。但若视频文件没做 faststart 优化，moov 在文件末尾，浏览器只能一路下载直到它出现——实测常见 MP4 会下 50–200 KB 才停，远超预期。
- 用
ffprobe video.mp4查看moov位置：若显示moov @ end，就属于高风险文件 - Nginx 默认不返回
Accept-Ranges: bytes，浏览器无法发Range请求，只能 GET 全量 - 即使设了
preload="metadata"，只要<video></video>已挂载 DOM 且src静态存在，Chrome 桌面版仍可能悄悄拉取前几 KB（约 0.2–0.3 KB）用于 MIME 类型识别
让 metadata 真正只传几 KB 的硬性条件
两个条件缺一不可，否则 preload="metadata" 就是假节省：
- 服务端必须响应
Accept-Ranges: bytes—— Nginx 需显式开启add_header Accept-Ranges bytes;，并确保MP4/MP3文件类型已配置Content-Length - 视频文件必须重写为
faststart格式：用ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4，把moov移到开头
满足后，实测流量稳定在 4–12 KB，且 loadedmetadata 事件可可靠触发。
立即学习“前端免费学习笔记（深入）”；
preload="metadata" 配合 poster 和 JS 的最小安全用法
光设属性不够，得补上三件事，否则用户看到白屏或控件异常：
- 必加
poster属性：<video poster="cover.jpg" preload="metadata"></video>，避免元数据加载期间空白 - 别依赖
video.readyState初始值，监听loadedmetadata事件再启用播放按钮或显示时长 - 列表页中每个
<video></video>都要设唯一id，方便后续用 JS 区分状态；若滚动进视口才加载，应动态改preload并调用.load()，而非一开始就全设metadata
最常被忽略的点：iOS Safari 对 preload 完全无视 auto，但对 metadata 是真支持——前提是服务端和文件都达标。一旦漏掉 faststart 或 Accept-Ranges，连 iOS 也会被迫多下几十 KB。
