必须用as="image"，否则预加载资源无法进入图片缓存池，导致后续<img>无法复用而重复下载；as值错误、路径不一致、MIME不匹配或响应头禁用缓存均会使预加载失效。
preload图片必须用as="image"，否则不进图片缓存池
浏览器对不同资源类型使用完全独立的缓存分区和解码策略。as="image"不是可选修饰，它直接决定预加载结果能否被后续 <img> 标签复用。如果写成 as="fetch" 或漏掉，即使 URL 完全一致，浏览器也会把预加载内容扔进通用 fetch 缓存区——而 <img> 只认图片缓存，导致重复下载。
常见错误包括：
-
as="img"或as="picture"：无效值，标签被忽略 -
as="image"但没配fetchpriority="high"：在 Chrome 101+ 中优先级仍为 Low，可能被关键 JS/CSS 挤出请求队列 - 同一张图在 HTML 中用
<img src="/a.webp">，但 preload 写的是href="/a.webp?ts=123"：带查询参数的 URL 被视为不同资源，无法复用缓存
WebP/JPEG/AVIF 预加载需与实际使用格式严格一致
浏览器不会自动转换或降级预加载结果。你 preload /hero.webp，但页面里 <img> 的 srcset 最终选中了 /hero.jpg，那预加载就白做了——两个文件哈希不同、MIME 不同、解码器也不同。
解决办法只有两种：
立即学习“前端免费学习笔记（深入）”；
- 只 preload 确定会被使用的单一格式（比如已通过
Accept请求头或 JS 特性检测确认支持 WebP，就只 preload WebP） - 对 fallback 格式也单独 preload（例如同时写两行：
<link rel="preload" as="image" href="/hero.webp">和<link rel="preload" as="image" href="/hero.jpg">），但要注意这会占用双倍带宽
别指望 <picture> 的 srcset 解析逻辑能触发 preload——它运行时才执行，浏览器静态解析阶段根本看不到。
CDN 缓存头和 ETag 必须允许复用
preload 是一次独立 HTTP 请求，它的响应是否能进缓存、是否能被后续 <img> 复用，完全取决于响应头。哪怕 HTML 里写对了 as="image"，只要服务器返回：
-
Cache-Control: no-store或no-cache→ 浏览器不缓存预加载内容 -
Vary: Accept但没在 preload 请求头里发Accept: image/webp→ CDN 可能返回不同变体，导致缓存不命中 - 缺失
ETag或Last-Modified→ 浏览器无法做强缓存校验，下次仍要发条件请求
验证方式：打开 DevTools → Network → 找到 preload 请求 → 查看 Response Headers。重点盯 cache-control、etag、content-type 是否合理。
动态路径或变量插值会让preload彻底失效
<link rel="preload"> 是纯静态声明，浏览器在 HTML 解析第一遍时就发起请求。任何 JS 模板语法、服务端变量（如 href="/assets/${name}.webp"）、或相对路径计算错误，都会导致请求 404 或指向错误资源。
典型陷阱：
- HTML 在
/user/profile.html，却写href="./images/hero.jpg"→ 实际请求变成/user/images/hero.jpg，而非预期的/images/hero.jpg - 用构建工具注入环境变量，但未在构建时展开（如 Vite 的
import.meta.env.BASE_URL没被正确替换） - CDN 域名变更后，preload 的
href还是旧地址，而页面中<img>已切新域名 → URL 不一致，缓存不复用
真正可靠的写法只有绝对路径或根路径：href="/images/hero.webp"，且必须和最终 <img src> 的 URL 字符串完全一致。
