preload 是浏览器预加载建议而非开关，实际执行受设备、网络、系统影响；none不主动请求主体但可能取首帧，metadata仅加载moov头（需服务端支持Accept-Ranges且MP4经faststart优化），auto在iOS Safari中被忽略、Chrome可能降级；首屏主视频推荐metadata，列表页用none+懒加载，移动端尤其需注意平台限制。
preload 属性不是开关，而是浏览器预加载的“建议”，实际是否执行、执行多少，由设备类型、网络状态、系统设置共同决定。用对了能减少点击等待，用错了反而拖慢首屏、浪费用户流量。
三个取值的真实行为
none、metadata、auto 看似简单，但各自触发的行为差异很大：
- none：浏览器不主动请求视频主体，也不保证元数据不加载——部分浏览器仍会取首帧或少量字节来判断宽高/格式，但不会解析完整 moov 头；适合非关键视频、列表页缩略图、弱网优先场景
- metadata：只请求视频文件头部（如 MP4 的 moov box），用于获取时长、尺寸、封面帧、音轨信息等；体积通常仅几 KB，响应快、兼容性好；前提是服务端支持 Accept-Ranges: bytes，且视频经 faststart 优化（moov 在开头）
- auto：浏览器可完全忽略该值；iOS Safari 从 iOS 10 起一律降级为 none；Chrome 桌面版可能缓存前几秒，但若检测到 “Save-Data” 或低电量模式，也会退化为 metadata；它不是加速指令，而是风险提示
不同场景下的推荐配置
不靠经验猜测，而按视频位置与用户意图选择：
- 首页首屏主视频、产品介绍页核心视频：用 preload="metadata" —— 封面立刻显示、进度条准确、用户点播即加载主体，体验与资源消耗平衡
- 信息流/短视频列表：所有视频默认 preload="none"，再配合 loading="lazy" 和 IntersectionObserver，仅对视口内及邻近 1–2 个元素动态设 preload="metadata" 并调用 load()
- 已知用户大概率播放的单页主视频（如课程详情页）：可设 preload="metadata"，并在用户滚动进入视口后 JS 调用 load()；不建议直接写 auto，尤其在移动端
比 preload 更关键的底层条件
preload 能否真正起效，依赖几个常被忽略的前提：
立即学习“前端免费学习笔记（深入）”；
- 服务端必须返回 Accept-Ranges: bytes 响应头，否则 metadata 模式可能被迫下载前几 KB 甚至整个文件
- MP4 视频需用 ffmpeg -c copy -movflags +faststart 重写，确保 moov box 位于文件开头，否则浏览器无法跳过主体直接读元数据
- preload 属性只在 HTML 初始解析阶段生效；JS 动态插入的 video 元素，无论怎么设 preload 都不会触发预加载，必须显式调用 load()
- 可搭配 <link rel="preload" as="video" href="xxx.mp4"> 主动发起同域资源预连接与缓存，但它不触发解码，也不影响 video 元素自身状态
移动端与嵌入视频的特殊限制
很多问题不是代码写错，而是平台策略所致：
- iOS Safari 对 preload 完全无视，无论设 auto/metadata/none，初始均按 none 处理；video.readyState 长期为 0，直到用户点击才开始加载
- 安卓 WebView 行为碎片化，部分版本直接忽略 preload；第三方 iframe 视频（如 YouTube、Vimeo）中 preload 属性完全无效，加载逻辑由其自身播放器控制
- autoplay 必须配合 muted + playsinline 才可能生效，且 preload 在 autoplay 存在时通常被浏览器忽略
