preload是弱提示而非强制指令，其实际效果受浏览器、设备、网络策略及服务端配置影响；iOS Safari无视auto，Chrome常降级为metadata，验证需查Network面板或video.readyState≥2。
preload 属性不是开关，是弱提示——写 preload="auto" 不代表视频真开始下载，设 preload="none" 也不等于浏览器完全不发请求。它实际生效与否，取决于浏览器实现、设备类型、网络策略，甚至服务端响应头。
为什么写了 preload="auto" 却没看到请求？
iOS Safari 从 iOS 10 起就无视 preload 值，一律按 none 处理；Android Chrome 在无用户手势上下文中也会降级为只取元数据；即使桌面 Chrome，也常把 auto 当作 metadata 执行——只拉 moov box（含时长、宽高），而非整个文件。
真正能验证是否预加载的，只有两点：
- 打开浏览器开发者工具的 Network 面板，过滤
.mp4或.m4a，看请求是否在DOMContentLoaded之前发出 - 检查
video.buffered.length是否 > 0，或监听loadedmetadata后立刻查video.readyState是否 ≥ 2（HAVE_METADATA）
preload="metadata" 是最稳妥的选择吗？
是，但有前提：服务端必须支持字节范围请求（即响应头含 Accept-Ranges: bytes）。否则浏览器为读取 moov box 可能被迫下载整个 MP4 前几 MB，反而更耗流量。
立即学习“前端免费学习笔记（深入）”；
常见问题包括：
- 用 Nginx 默认配置托管视频时，
preload="metadata"在某些版本中会退化为全量下载 - FFmpeg 转码后未加
-movflags +faststart，moov box 在文件末尾，浏览器无法“只取头部” - CDN 缓存了不带
Accept-Ranges的响应，导致后续所有请求都失效
移动端和微信内嵌浏览器怎么处理 preload？
基本不可信。iOS 和 Android WebView 的媒体策略优先级远高于 HTML 属性。微信 X5 内核对 audio 更激进：哪怕 preload="none"，只要调用 play()，X5 就立即发起请求并缓存前 1–2MB；而 video 标签在微信里几乎完全忽略 preload，首次播放延迟由 UA 自主控制。
实操建议：
- 不要在页面初始化时就创建
audio元素，延迟到用户点击按钮后再new Audio(src) - 对关键音频，用 JS 主动调用
audio.load()，并监听canplaythrough而非依赖preload - 在微信中，若需首播极快，可预加载一个极小的静音 MP3（
比 preload 更可控的预加载方式有哪些？
单独靠 HTML 属性解决不了卡顿。真正起效的是组合手段：
- 用
<link rel="preload" as="video" href="main.mp4">主动触发 fetch，但注意仅同域有效，且不触发解码 - 服务端确保 MP4 文件已用
ffmpeg -c copy -movflags +faststart重排，moov 在开头 - JS 中提前实例化
Video并调用load()，但需判断readyState 再调，避免重复触发 - 对列表页多个视频，用
IntersectionObserver监听视口，进入可视区再设置preload="auto"并调用load()
最关键的一点：别把 preload 当控制指令，它只是给浏览器递一张便条。真正决定加载节奏的，是服务端配置、网络环境、用户交互时机，以及你有没有在 JS 里补上那句 video.load()。
