能，但只在完全不调用load()的前提下成立；它跳过dns、tcp、tls全过程，readystate长期为0，连首帧都拿不到，需配合intersectionobserver在视口内手动load()才能兼顾省流与体验。
preload="none" 在限流环境里真能省流量吗
能，但只在你完全不调用 load() 的前提下成立。它让浏览器跳过 DNS 查询、TCP 连接、TLS 握手全部环节，video.readyState 长期卡在 0（HAVE_NOTHING），连首帧封面都拿不到。
常见错误现象：
- 写了
preload="none"却直接显示时长或自动渲染 poster——根本不可能，元数据都没请求 - 信息流中所有视频都设为 none，但没监听视口，用户滑到眼前才开始拉流，首帧延迟明显
- 误以为 Chrome 对小 MP4 也会彻底静默——它可能仍会预读前几百 KB，尤其当
src是本地路径或同域 HTTP/2 连接复用时
使用建议：
- 微信内嵌 WebView、低配 Android 设备、蜂窝网络检测为 2G/3G 时，优先选
none - 必须配合
IntersectionObserver，进入视口后立刻调用video.load() - 微信 X5 内核对首次
load()有静默丢弃风险，可加setTimeout(() => video.load(), 0)微调
preload="metadata" 为什么是限流下的默认安全线
它只请求 MP4 文件开头的 moov box（通常几 KB），用于获取时长、宽高、封面帧、音轨数等，不下载任何画面帧或音频流。这是目前兼容性最好、副作用最小的取值。
但生效有硬前提：
- 服务端必须返回
Accept-Ranges: bytes响应头，否则浏览器无法发字节范围请求，可能退化为下载前几 MB 甚至整个文件 - 视频文件必须经
ffmpeg -c copy -movflags +faststart重写，否则moov在文件末尾，浏览器得下完才能解析 - 务必搭配
poster属性，避免白屏；监听loadedmetadata事件确认就绪，别信video.readyState初始值
性能影响：HTTP 请求体积小、失败成本低，适合弱网重试；iOS Safari、Chrome、Firefox 均稳定支持。
preload="auto" 在限流场景下基本无效
名字带 “auto”，实际几乎从不自动全量加载。iOS Safari 从 10 开始就无视所有 preload 值，静默降级为 none；Chrome 桌面版通常只加载前 1–5 秒；Android WebView 和微信内核也普遍降级为 metadata。
关键事实：
- 只要写了
autoplay，preload直接被忽略——不是 bug，是规范行为 - 动态 JS 设置
video.preload = "auto"完全不触发预加载逻辑，只在 HTML 解析阶段起作用 - 不要给列表页所有视频设
auto，大文件（>100MB）下极易耗尽带宽，拖慢其他资源
真正可控的做法：用 <link rel="preload" as="video" href="xxx.mp4" crossorigin> 主动抢带宽（仅同域有效），但它只下载不解码，不影响 video 元素状态。
限流策略里最容易被忽略的三个技术点
一是 preload 生效只在 HTML 解析阶段；动态插入的 <video></video> 即使带属性，也不会触发预加载——得靠 JS 显式调用 load()。
二是 <link rel="preload"> 和 video.preload 完全不互通：前者是独立资源调度，后者是元素级提示，两者生命周期、缓存分区、触发时机互不感知。
三是服务端若不支持 Range 请求，metadata 模式会失效；而 faststart 不是转码选项，是容器层重写操作，FFmpeg 命令漏掉 -movflags +faststart 就等于白配。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
