as="image"必须与实际资源类型严格匹配，否则缓存失效；需确保路径有效、MIME类型（Content-Type）、文件后缀及响应头三者一致，并配合fetchpriority="high"提升加载优先级。
as="image" 必须和实际图片格式严格对齐
浏览器对 as="image" 的缓存复用，依赖 MIME 类型、文件后缀、响应头三者一致。写 <link rel="preload" href="/hero.webp" as="image">，但服务端返回 Content-Type: image/jpeg，或路径实际返回的是 PNG（比如 Nginx 重写规则把 .webp 请求 fallback 到 .png），缓存就失效——页面里 <img src="/hero.webp"> 仍会发起第二次请求。
常见踩坑点：
- CDN 或服务端配置了自动格式协商（如 Accept header → 返回 .avif），但 preload 的
href写死为 .webp，导致实际加载的资源类型不匹配 - Vite/webpack 构建时启用了
assetInlineLimit，小图被转成 data URL，而 preload 指向的是原始文件路径，完全不复用 - 开发环境用 Webpack Dev Server，生产环境走 CDN，两者对同一路径返回的 MIME 不一致（比如本地是
image/webp，CDN 是image/png）
WebP/AVIF 预加载必须配合 fetchpriority="high"
Chrome 101+ 中，fetchpriority="high" 才能让 as="image" 请求进入 Highest 优先级队列；没加的话，即使路径和类型都对，弱网下仍可能被 CSS 或字体挤到后面，首屏图加载延迟 300ms+。
注意：fetchpriority 不影响缓存逻辑，只影响调度顺序。它和 as 是协作关系，不是替代关系：
立即学习“前端免费学习笔记（深入）”；
- 漏
as="image"→fetchpriority="high"被忽略，Priority 显示为 Low - 有
as="image"但没fetchpriority="high"→ Priority 多数情况是 High，但非弱网场景下不稳定 - 两者都有 → Network 面板中该请求的 Priority 列明确显示为 Highest
srcset 场景下 preload 几乎无效，别硬套
<img src="/hero.jpg" srcset="/hero-768w.jpg 768w, /hero-1200w.jpg 1200w"> 这种写法，浏览器根据设备宽度和 DPR 动态选图。你 preload 其中任意一个尺寸（比如 /hero-1200w.jpg），只要设备最终选中的是另一个（比如 /hero-768w.jpg），就不会复用——两个 URL 被视为完全不同的资源。
真正有效的做法只有两种：
- 只预加载明确用于当前设备的单图：通过服务端 User-Agent 检测或 JS 运行时判断后，动态注入唯一匹配的
<link rel="preload">（注意：不能靠 JS 插入，必须在 HTML 初始解析阶段完成） - 放弃 preload，改用
<img fetchpriority="high">—— 它能触发浏览器对当前src或匹配srcset的那个 URL 提升优先级，且无需额外标签
验证缓存是否命中，看 Network 面板的两个字段
别只盯着 Status 是不是 200。关键要看：
-
Initiator列是否为preload（不是parser或script） -
Size列是否显示from memory cache或from disk cache（而非from network）
如果 Initiator 是 preload 但 Size 是 from network，说明缓存未命中——问题一定出在路径、MIME、CORS 或 format 协商上；如果 Initiator 是 parser，说明 preload 根本没生效（位置错、as 错、或被浏览器忽略）。
WebP/AVIF 的缓存链路比 JPEG 更脆弱，稍有不一致就断。与其反复调参，不如先确认服务端返回的 Content-Type 和实际二进制格式是否真一致——这是所有 preload 缓存优化的前提。
