preload="metadata"仅触发一次http请求（head或get），用于获取响应头及解析mp4的moov box，不加载音视频帧；若服务端不支持accept-ranges或moov在文件末尾，则可能卡住或失败。
preload="metadata" 到底会触发哪些网络请求？
它不会加载视频主体数据，但会触发一次 HTTP HEAD 或 GET 请求，目标是获取 Content-Length、Content-Range、Accept-Ranges 等响应头，用于判断是否支持分片（byte-range）请求，并尝试解析容器头部（如 MP4 的 moov box）。如果服务器不支持范围请求或 moov 位于文件末尾（常见于未优化的 MP4），这个阶段就可能卡住或失败。
- 实际行为取决于服务端是否返回
Accept-Ranges: bytes - 某些 CDN 或代理会忽略 HEAD 请求，降级为 GET，且可能缓存不友好
- 若视频是 HLS 或 MSE 流（
src指向 .m3u8 或通过MediaSource动态赋值），preload="metadata"基本无效——浏览器不解析 m3u8，也不会发起任何分片请求
和 preload="none" / "auto" 相比，首帧耗时差异在哪？
关键不在“是否加载”，而在“何时开始加载”。preload="metadata" 把首帧依赖的元数据拉取提前到 video 元素创建后、play() 调用前；而 preload="none" 下，首次 play() 才触发元数据请求 + 首帧解码；preload="auto" 则可能预加载几秒数据（行为因浏览器、带宽策略而异，不可控）。
- 实测中，
preload="metadata"比none平均快 100–300ms 首帧渲染（尤其在弱网或高延迟 DNS/SSL 场景） - 但若页面有多个
video，全部设为metadata会造成并发元数据请求，可能触发浏览器连接数限制或被服务器限速 -
auto在移动端常被浏览器主动降级为none（省流量策略），不可依赖
流媒体场景下它为什么经常“没反应”？
因为 preload 是为传统 HTTP progressive download 设计的，对基于分片协议的流媒体（HLS、DASH、WebRTC）天然不适用。当 src 是 .m3u8 地址时，浏览器根本不解析该文件，更不会提取第一个 .ts 片段地址去请求；一切调度由 JavaScript（如 hls.js）或原生 MSE 控制。
- 即使你写了
<video preload="metadata"></video>，只要后续用Hls.loadSource()或mediaSource.addSourceBuffer()，preload 行为就被完全绕过 - 想优化首帧，得在 JS 层控制：比如提前 fetch 第一个 m3u8，解析出首个 ts URL 并预热 DNS + TCP + TLS，甚至用
fetch()触发缓存预热（注意跨域和 CORS） - 部分播放器（如 Video.js + http-streaming）会忽略
preload，直接接管加载逻辑
生产环境建议怎么配？
别一刀切。优先按使用方式决策：
- 纯
src直连 MP4/WEBM：设preload="metadata"，并确保服务端返回Accept-Ranges: bytes，MP4 已用ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4优化 - 用 hls.js / dash.js：移除
preload属性，或显式设为none，避免误导；首帧优化交给播放器实例的load({ startPosition: 0 })或自定义 buffer 策略 - 广告插播或画中画等需快速启动的场景：可对主视频元素用
preload="metadata"，但务必监听loadedmetadata后再调用play()，防止 iOS Safari 因自动播放策略静音阻塞
最易被忽略的一点：iOS Safari 对 preload 的实现最保守——即使设了 metadata，也可能延迟到用户交互后才真正发起请求。所以任何依赖“预加载完成”的逻辑，都必须兼容 fallback 到事件驱动流程。
