preload="none" 能省流量，但仅在未调用 load()、未触发 play() 且视频元素未插入 DOM 前生效；它使浏览器跳过 DNS 查询，readyState 长期为 0；小体积探测请求（如 HEAD 或 Range）属合法行为，>10 KB 请求说明已触发加载。
preload="none" 能省流量，但只在你没调用 load()、没触发 play()、且视频元素没被插入 DOM 之前成立。它不是“禁止加载”，而是把加载决策权彻底交还给 JS —— 浏览器连 DNS 查询都跳过，video.readyState 会长期卡在 0（HAVE_NOTHING）。
为什么写了 preload="none" 还看到 Network 里有请求？
常见错误现象：DevTools Network 面板出现小体积请求（0.2–0.3 KB），状态码 206 或 200，Response Headers 里有 Content-Range 或 Accept-Ranges: bytes。
- 这是浏览器发的
HEAD或Range: bytes=0-1023探测请求，只为确认资源存在、获取宽高和编码格式，属于none模式下的合法行为，不算“破戒” - 如果看到 >10 KB 的请求，说明你已调用
video.load()、或video.src已赋值且元素已挂载、或用户已点击播放 —— 此时preload属性早已失效 - 微信 X5 内核对首次
load()有静默丢弃风险，建议写成setTimeout(() => video.load(), 0)微调
preload="none" 必须配合 IntersectionObserver 才有用
单纯设属性不监听视口，等于白设。用户滑到眼前才开始拉流，首帧延迟会非常明显，尤其在低配 Android 或蜂窝网络下。
- 不要用
scroll事件做判断，性能差且易漏帧；必须用IntersectionObserver监听进入视口 - 观察到
isIntersecting === true后，立刻执行video.src = dataSrc（从data-src取真实地址），再调用video.load() - 若
video是懒加载列表中的一员，确保每个实例都绑定独立 observer 实例，避免复用导致状态错乱
移动端 Safari 和微信 WebView 的特殊行为
iOS Safari 对 preload 最严格：哪怕设了 "auto"，没用户手势也等同于 "none"；微信 X5 内核则可能对小 MP4 偷偷预读前几百 KB，尤其当 src 是同域 HTTP/2 资源时。
立即学习“前端免费学习笔记（深入）”；
- 在检测到
navigator.connection.effectiveType为"2g"或"3g"时，强制设preload="none"并禁用自动播放 - 不要同时写
autoplay和preload="none"—— 语义冲突，部分安卓 WebView 会因muted存在而反向激进预加载 - 验证是否真省流量？打开 Chrome DevTools → Network → Filter:
media，确认所有视频请求都出现在用户交互之后，且首屏无主体数据下载
真正省流量的关键不在属性值本身，而在你是否把 src 赋值、load() 调用、play() 触发，全部约束在明确的用户意图之后。没有用户交互，就别让任何音频或视频资源进入加载队列。
