as="video"仅适用于<video>元素的src属性，不支持poster、<source>子标签或JS动态URL；需严格匹配URL字符串、正确设置type且与服务端Content-Type一致。
as="video"只对
浏览器把 as="video" 当作一个专用通道，仅服务于 <video> 元素的 src 属性。它不会匹配 poster 图、<source> 子标签（除非你手动写成 <link rel="preload" as="video"> 并确保 href 和 <source> 的 src 字符串完全一致），更不适用于通过 JS 动态设置的视频 URL。
常见误用包括：
- 给封面图（
poster）写as="video"→ 封面是图片，该用as="image" - 预加载 MP4 却在
<video>中实际用 WebM → URL 不同、MIME 不同，无法复用 - 用
as="media"或as="mp4"→ 这些值不在规范列表中，浏览器静默忽略整条<link>
预加载视频时漏掉 type 或写错 MIME 会导致降级或失败
type 属性虽非强制，但对视频很关键：它跳过浏览器的 MIME 探测（sniffing），避免因服务端未返回正确 Content-Type 而被拒绝加载。尤其当 CDN 缓存了错误响应头，或后端未配置好 AVIF/WebM 的类型映射时，type 就是兜底项。
正确写法示例：
立即学习“前端免费学习笔记（深入）”；
<link rel="preload" href="/videos/hero.mp4" as="video" type="video/mp4"> <link rel="preload" href="/videos/hero.webm" as="video" type="video/webm">
注意：type 必须与服务端实际返回的 Content-Type 一致；若不一致（比如写了 type="video/mp4" 但服务器返回 video/webm），Chrome 会报 MIME type mismatch 并中断加载。
as="video" 不触发自动解码，也不影响 poster 渲染时机
预加载只是把字节拉到内存或磁盘缓存，as="video" 不会让浏览器提前解码帧、生成纹理或准备播放器上下文。它只提升网络层就绪速度——真正调用 video.play() 或用户点击播放时，才开始解码和渲染。
这意味着：
-
poster图片仍按原逻辑加载和显示，预加载视频对它无加速作用 - 即使视频已 preload 完毕，首次播放仍可能有短暂卡顿（取决于设备解码能力）
- 不能靠
as="video"规避 iOS 的“点击才能播放”限制
路径必须完全一致，连查询参数都不能差
浏览器判断预加载能否被 <video src> 复用，只看 URL 字符串是否逐字相等。构建工具加哈希、版本号、A/B 测试参数，极易踩坑。
例如：
- 预加载写的是
/videos/hero.mp4?v=1.2，但<video src>是/videos/hero.mp4→ 不复用 - 预加载用
https://cdn.example.com/hero.mp4，<video>用相对路径/videos/hero.mp4→ 不复用（协议 + 域名不同） - 大小写差异：
/Videos/hero.mp4vs/videos/hero.mp4→ 不复用
最稳妥的做法是：构建时统一管理视频路径变量，确保预加载 href 和运行时 src 来自同一份字符串源。否则，你看到 Network 面板里有两个请求，控制台却没有任何提示。
