preload图片必须写在html解析阶段的中且不可动态插入，as="image"为硬性要求，路径需绝对、无js变量，仅适用于尺寸格式确定的单图；验证需看network面板initiator为preload且priority为highest。
preload图片必须写在里，且不能动态插入
浏览器只在解析 HTML 时识别 <link rel="preload">，一旦进入 DOM 构建阶段或 JS 执行期，再用 document.createElement('link') 插入就完全无效。很多实测失败案例，根源就是把 preload 放在 里、或塞进某个组件的 mounted 钩子中。
真实场景中容易踩的坑：
- 路径写成相对路径（如
./img/hero.jpg），而 HTML 文件在子目录下，导致 404 - href 值含 JS 变量或模板语法（如
href="/img/${name}.webp"），浏览器当字面量处理，直接请求错误 URL - 多个 preload 标签堆在一起但没加
fetchpriority="high"，Chrome 101+ 会按默认 priority 调度，首屏图可能排在字体之后
as="image" 是硬性要求，不是可选装饰
漏写 as="image" 或写成 as="fetch"，浏览器就当普通 fetch 处理，Priority 降为 Low，Network 面板里 Initiator 显示为 parser 而非 preload，实测加载延迟常达 200–400ms。
关键差异点：
-
as="image"触发图片专用缓存逻辑和 MIME 校验，能复用后续<img src>的请求 - 不支持
srcset或sizes，只适合尺寸/格式确定的单图（如 banner、logo） - 对普通
<img src>本身不起作用——它只预载资源进缓存，不触发渲染
验证 preload 是否生效，得看 Network 面板的两个字段
光检查 HTML 里有没有那行代码毫无意义。打开 Chrome DevTools → Network，必须同时满足以下两点才算真正起效：
- Filter 中输入
Initiator: preload，确保看到对应图片请求 - 该请求的
Priority列显示为Highest（as="image"）或High（as="style"），不是Low
如果 Priority 是 Low，90% 是 as 漏写或类型错配；如果 Initiator 是 parser，说明标签位置错了或被 JS 动态插入。
别对普通 ![]()
加 preload，改用 fetchpriority="high"
这是最常被误用的点：<img src="hero.jpg"> 本身已由浏览器自动发现，再加 <link rel="preload" as="image" href="hero.jpg"> 不仅冗余，还可能因路径大小写、查询参数差异（如 ?v=1）导致缓存不匹配，反而多一次请求。
正确做法是直接在 <img> 上加属性：
- Chrome 101+：加
fetchpriority="high"，语义清晰、无兼容风险 - 旧版浏览器：靠
loading="eager"+ 提前写在 HTML 中（比 JS 动态插入早） - 真正需要 preload 的，只有那些浏览器“发现太晚”的图：比如内联
style里的background-image、<picture></picture>中关键<source></source>的 URL
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
