as="video"仅预加载video元素的src资源，不作用于poster图；需在初始HTML中声明video元素、添加crossorigin属性，并配合preload="metadata"等策略才能有效优化首帧。
as="video"只对
很多人以为写了 <link rel="preload" as="video"> 就能提前加载视频封面或背景图，其实它只匹配 <video> 元素的 src 属性值。如果预加载的是 cover.jpg 却写成 as="video"，浏览器会按视频流逻辑处理（比如发 range 请求、进 video 缓存池），反而拖慢渲染，且无法被 <img> 复用。
真正该用 as="video" 的场景只有一个：你有一个 <video src="main.mp4">，且希望它在 HTML 解析阶段就发起下载。
- 海报图（.jpg/.png）→ 必须用
as="image" - 主视频资源（.mp4/.webm）→ 才用
as="video" - 动态插入的
<video>→link preload无效，必须初始 HTML 中已存在
跨域视频必须加 crossorigin，哪怕同源也得加
as="video" 触发的是 fetch 级别请求，默认走 anonymous CORS 模式。这意味着：即使视频和页面同属 https://example.com，只要没写 crossorigin，浏览器就会静默丢弃响应——Network 面板里能看到请求发出、状态码是 0、缓存为空。
常见错误写法：<link rel="preload" href="https://cdn.example.com/clip.mp4" as="video">（漏 crossorigin）
立即学习“前端免费学习笔记（深入）”；
正确写法：<link rel="preload" href="https://cdn.example.com/clip.mp4" as="video" crossorigin>
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 服务端响应头必须含
Access-Control-Allow-Origin: *或对应域名，否则仍被拦截 -
crossorigin="use-credentials"基本不用——CDN 几乎不支持带 cookie 的视频请求 - iOS Safari 中即使全配对，
as="video"也大概率不进缓存，别依赖它
preload="video" 不等于 video.preload="metadata"
<link rel="preload" as="video"> 和 <video preload="metadata"> 完全无关。前者是 HTML 解析期的独立下载指令，后者是元素自身的加载策略建议，两者生命周期、触发时机、缓存复用路径全部隔离。
这意味着：
- 写了
link preload但没在 HTML 里声明<video>，资源下载完也白费 - JS 动态创建
<video>后再设src，不会自动复用已预加载的字节流 -
video.readyState依然可能长期为0（HAVE_NOTHING），必须等用户交互或显式调用load()才开始解析元数据 - 想自动播放？不能靠 preload 后直接
play()，得监听canplay或loadeddata事件
它只下载，不解码，也不影响 video 元素状态
as="video" 的作用非常窄：仅提前建立连接、发 HTTP 请求、把原始字节存入 HTTP 缓存。它不会触发视频解码，不会让关联的 <video> 进入 canplay 状态，更不会自动填充 video.duration 或 video.videoWidth。
所以别指望它解决“首帧延迟”问题。真正可控的做法是：
-
<video>必须在初始 HTML 中存在（哪怕display: none） - 配合
preload="metadata"+ faststart 视频 + 服务端返回Accept-Ranges: bytes -
link preload只作为同域下的带宽抢跑补充，不能替代元素级控制
最常被忽略的一点：iOS Safari 对 as="video" 的实现基本形同虚设——它可能发请求，但几乎不缓存，后续 <video> 仍会重新 fetch。别把它当跨平台通用方案。
