preload 属性实际效果取决于值与环境：“auto”不保证加载，iOS Safari 忽略；“metadata”最稳妥，仅获取元信息；“none”非绝对阻止，Chrome 可能预读小文件；移动端常失效，需结合事件监听与 UA 判断。
preload 属性值选哪个才真正起作用
浏览器是否预加载，不只看 preload 写没写，更取决于值和实际环境。设成 "auto" 不等于一定加载，设成 "none" 也不绝对阻止——尤其在移动 Safari 上，它会无视 preload="auto"，强制按需加载以省流量。
-
"auto"：建议浏览器加载，但由 UA 自主决定；桌面 Chrome 多数会加载前几秒，iOS Safari 直接忽略 -
"metadata"：只取时长、尺寸、封面等元信息，最稳妥的选择，兼容性好、无带宽浪费 -
"none"：仅提示“暂不加载”，用户点播放后仍可能触发预缓冲（比如 Chrome 对小体积 MP4 会悄悄预读）
移动端 video 标签 preload 基本无效的真相
iOS 和 Android WebView 的媒体策略优先级远高于 HTML 属性。Safari 从 iOS 10 起就禁用 preload，Android Chrome 在非用户手势触发场景下也会降级处理。
- 即使写了
preload="auto"，video.readyState仍常为0（HAVE_NOTHING），直到用户点击播放 - 想提前获取时长？必须靠
loadedmetadata事件，不能依赖preload是否生效 - 自动播放（
autoplay）开启时，部分安卓浏览器会顺带加载部分数据，但这不是preload的功劳
audio 标签 preload 在微信内嵌浏览器的特殊表现
微信内置 X5 内核对 audio 的 preload 处理比 video 更激进：哪怕设 "none"，只要调用了 play()，X5 就会立即发起请求并缓存前 1–2MB。
- 实测中，
preload="metadata"和"none"在微信里行为几乎一致 - 若音频源是 HTTPS 且小于 5MB，X5 很可能全量缓存到内存，导致首次播放极快，但用户没点播也耗了流量
- 避免误伤：不要在页面初始化时就创建
audio元素，延迟到用户交互后实例化更可控
用 JavaScript 检测 preload 实际效果比写属性更重要
光靠 HTML 属性无法确认是否真加载了。得监听事件 + 查状态，否则容易误判缓冲进度或网络行为。
立即学习“前端免费学习笔记（深入）”；
- 监听
loadedmetadata确认元信息已就绪，而不是等canplay - 检查
video.buffered.length和video.buffered.end(0)判断已缓内容范围 - 网络面板里搜
.mp4或.m4a请求，看是否在页面 load 完成前就发出了——这才是 preload 生效的铁证
preload 更像一个弱提示，而不是控制开关。真要控制加载节奏，得结合懒加载逻辑、preload 属性、事件监听和 UA 特性判断，缺一不可。 
