preload="metadata"被推荐是因为它仅请求视频头部（moov box）获取元数据，不下载音视频帧，但前提是服务端返回Accept-Ranges: bytes且MP4经faststart优化使moov位于开头。
preload 属性不是开关，设了不等于生效；真正影响性能的，是它和服务端配置、文件结构、浏览器策略三者的配合。
preload="metadata" 为什么常被推荐？
它只请求视频头部（moov box），用于获取时长、宽高、码率等元数据，不拉整个文件。但这个“只取头部”有个硬前提：Accept-Ranges: bytes 响应头必须存在，且 MP4 文件的 moov box 必须在开头。
- FFmpeg 转码后没加
-movflags +faststart→ moov 在文件末尾 → 浏览器为读元数据可能下载前几 MB - Nginx 默认配置不返回
Accept-Ranges→ 某些版本会退化为全量下载 - CDN 缓存了不含字节范围支持的响应 → 后续所有请求都失效
- Chrome 实际常把
preload="auto"降级为metadata，iOS Safari 则直接无视auto
preload="none" 真的不发请求吗？
不一定。尤其在微信 X5 内核中：preload="none" 对 几乎无效——只要调用 play()，X5 就立刻发起请求并缓存前 1–2MB； 更彻底，首次播放延迟由 UA 自主控制，HTML 属性基本无干预能力。
- 移动端 WebView（尤其 iOS）优先执行系统媒体策略，
preload是弱提示，非强制指令 - 不要在页面初始化就创建
Audio实例，延迟到用户点击后再new Audio(src) - 关键音频建议用 JS 主动调用
audio.load()，并监听canplaythrough，比依赖preload更可控
比 preload 更靠谱的预加载方式有哪些？
单靠 HTML 属性解决不了卡顿。真正起效的是组合手段：
-
：主动触发 fetch，但仅同域有效，且不触发解码 - 服务端确保 MP4 已用
ffmpeg -c copy -movflags +faststart重排，moov 在开头 - JS 中提前实例化
Video并调用load()，但注意：必须在用户手势上下文（如 click、touchend）中执行，否则 Chrome 会静默拒绝 - 对首播极快要求高的场景，可预加载一个 50KB 以内的静音 MP3（如 1 秒空白音频），比依赖
preload更稳定
最容易被忽略的一点：验证是否真预加载，不能只看属性写了什么，得打开 Network 面板过滤 .mp4，确认请求是否在 DOMContentLoaded 前发出；或者检查 video.buffered.length > 0 或 video.readyState >= 2。否则你优化了半天，浏览器根本没理你。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
