preload="metadata"是最稳妥的默认值，因只拉取几KB的moov头信息（时长、宽高、封面等），适用于可能划走的列表页场景，但需服务端支持Accept-Ranges: bytes且moov在文件开头（FFmpeg加-faststart），并配合poster与loadedmetadata事件；iOS Safari无视所有preload值，一律降级为none，须用IntersectionObserver+video.load()主动控制。
preload="metadata" 为什么是最稳妥的默认值
它只拉取视频头信息（moov box），包括时长、宽高、封面帧、音轨数等，体积通常几 KB，不下载画面帧。适用于视频列表页、卡片流、搜索结果页这类“可能看，也可能划走”的场景。
但前提是服务端必须返回 Accept-Ranges: bytes 响应头，否则浏览器无法做字节范围请求，preload="metadata" 可能退化为下载前几 MB 甚至整个文件。
- FFmpeg 转码后务必加
-movflags +faststart，否则moov在文件末尾，metadata 模式失效 -
poster属性要配合使用，能立刻显示占位图，避免空白闪烁 - 监听
loadedmetadata事件确认元信息就绪，别依赖video.readyState判断是否“已预加载”
iOS Safari 对 preload 的处理是铁律
iOS Safari 从 iOS 10 开始，无视所有 preload 值（包括 "auto"），一律静默降级为 "none"。这不是 bug，是苹果强制的流量与电池策略。
这意味着：video.readyState 在 iOS 上长期卡在 0（HAVE_NOTHING），直到用户点击播放才开始动；写 preload="auto" 等于没写，不如省掉这行代码。
立即学习“前端免费学习笔记（深入）”；
- 不要靠 UA 字符串检测 iOS 后再设
auto——写了也没用 - 若需首帧快，必须靠 JS 显式调用
video.load()，且建议加setTimeout(() => video.load(), 0)微调（微信 X5 内核有静默丢弃风险） - 完全移出可视区后，建议设
src = ""释放已加载资源（注意：这会中断正在进行的请求）
动态插入的 video 元素，preload 属性基本无效
动态插入的 <video></video> 即使带 preload="auto"，也不会触发预加载——它压根没进初始 HTML 解析流程。想实现“即将进入视口时才加载”，必须用 IntersectionObserver 监听可见性，然后显式调用 video.load()。
- 调用
load()后，需监听canplay或loadeddata才能安全展示控件或自动播放 - 不要给列表页所有
<video></video>都设preload="metadata"，滚动时频繁创建/销毁元素会导致内存泄漏和卡顿 -
loading="lazy"对<video></video>无效（该属性仅支持<img alt="HTML元素preload属性怎么优化视频加载性能" >和<iframe></iframe>）
比 preload 更关键的是服务端配置和主动预加载
真正决定 preload 是否生效的，不在 HTML 里，而在服务端：没有 Accept-Ranges: bytes，preload="metadata" 就可能变成流量黑洞；moov 不在开头，首帧延迟就不可控。
更可控的做法是组合三层控制：
- 服务端：用
ffmpeg -c copy -movflags +faststart把moov移到文件开头 - HTML 层：
<link rel="preload" href="video.mp4" as="video">（注意必须写as="video"） - JS 层：在视口可见时调用
video.load()，并监听canplay防止重复触发
容易被忽略的是：移动端没有“后台预加载”概念，页面切到其他 tab 后，加载大概率被中止且不会恢复——依赖“提前加载完再播放”的逻辑在 iOS 上基本不可行。
