link rel="preload" as="video"会抢占带宽却无效，因其仅触发下载不触发解码、不改变video.readystate、不与互通，且ios safari中基本失效；跨域必须加crossorigin，服务端须返回access-control-allow-origin，否则静默失败。
link rel="preload" 加 as="video" 确实会抢占带宽，但它不是“视频预加载”的可靠方案——尤其在移动端，它只发请求、不触发解码、不关联 video 元素，且 iOS Safari 中基本无效。
为什么 as="video" 会抢带宽但没效果
浏览器把 as="video" 当作高优先级 fetch 请求处理，默认用 anonymous 模式（不带凭据），哪怕视频和页面同源，也必须显式加 crossorigin，否则请求虽发出，响应状态码为 0，资源进不了缓存池。
- 服务端若未返回
Access-Control-Allow-Origin，即使写了crossorigin，也会被拦截，Network 面板显示 CORS 错误，缓存失败 -
preload只下载字节流，不触发解码，也不影响video.readyState—— 它长期保持0（HAVE_NOTHING），尤其在 iOS 上 - 写了
preload却没在 HTML 中声明video元素，或动态插入后再赋值src，资源无法复用，等于白跑一次 high 优先级请求
as="video" 和 video.preload 完全不互通
link preload 是 HTML 解析阶段的独立调度指令；video.preload 是元素自身的加载策略建议。两者生命周期、触发时机、缓存分区互不感知。
- 同时写
<link rel="preload" as="video">和<video preload="metadata"></video>，浏览器可能发起两个独立请求：一个取元数据，一个取完整流，造成冗余 - 想让视频首帧秒出，
preload="metadata"+faststart视频 +Accept-Ranges: bytes响应头，比link preload更可控 -
link preload不能替代video元素级控制——它只适合同域下“抢带宽”作为补充，不是主策略
Chrome DevTools 里怎么验证它真起作用了
光看 HTML 有没有那行代码毫无意义，得进 Network 面板确认三件事：
- 筛选目标资源后，
Initiator列必须显示preload，不是parser或script -
Priority应为High（as="video"默认是 High，但若显示Low，基本可断定as写错或路径 404） - 跳转到下一页后，如果该视频又被用到，Network 中应出现
200 (from memory cache)；若仍是200 (disk cache)或网络请求，说明缓存未复用成功
真正容易被忽略的是：as="video" 的静默失效——浏览器不报错，但请求头错误、缓存分区错位、CORS 被丢弃，只能靠 Headers 标签页逐个核对 Accept 和 Content-Type 才能定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
