preload="none" 并非零请求，iOS Safari和多数Android WebView确实不发请求，但Chrome桌面版等可能发HEAD或Range请求获取元信息；preload="metadata"需服务端支持Accept-Ranges且视频经faststart优化才有效；移动端preload="auto"基本无效，省流量关键在于JS控制加载时机并绑定用户意图。
preload="none" 能省流量，但只在用户没点播放前有效；一旦调用 load() 或 play()，浏览器照常下载——它不是“禁止加载”，只是把请求推迟到你明确触发那一刻。
preload="none" 真的零请求？别信 readyState=0
设成 none 后，video.readyState 长期卡在 0（HAVE_NOTHING），看起来很干净。但现实是：
- iOS Safari 和多数 Android WebView 确实跳过 DNS/TCP/TLS 全流程，不发任何请求
- Chrome 桌面版或部分安卓 Chrome 可能仍会发一个
HEAD或带Range: bytes=0-1023的 GET，只为拿宽高和编码格式——这不算“加载主体”，但也不是 0 字节 - 微信 X5 内核对首次
load()有静默丢弃风险，得加setTimeout(() => video.load(), 0)微调
preload="metadata" 是省流又保体验的默认线
它只拉 MP4 文件开头的 moov box（通常几 KB），用于时长、封面帧、音轨数等，不下载画面或音频流。但生效要靠两个硬条件：
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- 服务端必须返回
Accept-Ranges: bytes响应头，否则浏览器可能退化为下载前几 KB 甚至整个文件 - 视频文件必须用
ffmpeg -c copy -movflags +faststart重写，否则moov在末尾，浏览器得下完才能解析 - 务必配
poster属性，不然白屏；监听loadedmetadata事件确认就绪，别信初始readyState
auto 不是“全量加载开关”，移动端基本无效
preload="auto" 在移动端几乎等于摆设：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 从 10 开始就无视所有
preload值，静默降级为none - 哪怕写了
autoplay，preload也直接被忽略——规范行为，不是 bug - 动态设置
video.preload = "auto"完全不触发预加载，只在 HTML 解析阶段起作用 - 想激进加载，得用
<link rel="preload" as="video" href="xxx.mp4">（仅同域），但它不触发解码，也不影响video元素状态
真正省流量的核心，不是属性值本身，而是把加载决策权从 HTML 移交给 JS，并确保每次 src 设置和 play() 调用都有明确的用户意图——没有用户交互，就别碰视频的网络请求。
