预加载图片必须写在 中、as="image" 不可省略、href 须与 完全一致（含查询参数），fetchpriority="high" 仅限 chrome 109+ 且慎用，不支持动态路径，srcset/sizes 需手动对齐，loading="lazy" 与 preload 冲突，首屏图需显式 loading="eager"。
用 <link rel="preload"> 配置图片预加载
真预加载只靠 <link rel="preload">，不是 img 标签加什么属性就能实现的。它必须写在 里，且浏览器会按优先级提前拉取资源，不阻塞渲染。
-
as="image"必须写，缺了会导致请求头错误、缓存策略失效，甚至被当成普通fetch请求处理 -
href值要和后续<img src>完全一致（包括查询参数），否则算两个资源，白占带宽还可能加载错尺寸 -
fetchpriority="high"只对 Chrome 109+ 有效，对首屏关键图（如 banner、logo）建议加上，但别滥用——同一页面超过 3 个 high 优先级预加载反而可能挤占其他关键资源 - 不支持动态路径：不能写
href="./images/<code>name.webp" 或模板语法，它是纯静态声明，服务端渲染时就得确定好最终 URL
srcset 和 sizes 不是预加载，但影响预加载效果
如果你用 <link rel="preload"> 预加载一张 WebP 图，但实际 <img> 标签靠 srcset + sizes 切换资源，那预加载很可能失效——因为浏览器无法自动映射 srcset 中的某一项到 href。
- 最稳妥的做法：只为
src指向的 fallback 图预加载，比如<img src="fallback.jpg" srcset="hero.webp 1x, hero@2x.webp 2x" sizes="100vw">，就只preloadfallback.jpg - 如果非要预加载 WebP 版本，得手动对齐：确保
<link href="/assets/hero.webp">和srcset中某一项路径完全相同，且该路径在目标设备上确实会被选中（可查 DevTools → Network → “Initiator” 列验证） -
sizes写错会导致浏览器选错srcset项，进而让预加载的图根本用不上——比如写了sizes="50vw"却在移动端全屏展示，结果加载了 600w 图，而你预加载的是 1200w 版本
别把 loading="lazy" 或 decoding="async" 当预加载用
这两个属性完全无关预加载：loading="lazy" 是推迟加载，decoding="async" 只控制解码时机。加了它们反而可能破坏预加载逻辑。
- 给同一个
<img>同时写loading="lazy"和<link rel="preload">是冲突行为，Chrome 会忽略preload或触发重复请求 -
decoding="async"对性能提升极小，且现代浏览器默认已优化解码，没必要显式设置；它不影响下载时间，只是把解码从主线程挪走 - 首屏图如果没写
loading="eager"，部分 Safari 版本（iOS 16.3 及更早）会直接跳过加载——不是懒，是彻底不加载，所以关键图必须显式声明eager，再配合preload
预加载路径写错的典型表现和自查点
预加载看似写对了，但 Network 面板里没看到请求，或请求了却没生效，大概率是路径或上下文出问题。
- 相对路径基于 HTML 文档位置解析，不是基于当前 JS 文件或 CSS 文件——比如 HTML 在
/pages/home.html，但写了href="images/logo.webp"，实际请求的是/pages/images/logo.webp，不是你预期的/assets/logo.webp - CDN 图片带参数（如
photo.jpg?w=480&f=webp）时，<link href>必须包含完整查询字符串，少一个&或参数顺序错，都算不同资源 - HTTP/2 下多个
preload可能被合并请求，但状态码为 200 并不表示内容被复用——要看 Response Headers 是否含content-length匹配，以及后续<img>加载时是否命中内存缓存（DevTools → Memory Cache 标签）
<img> 使用方式的严格对齐。最容易被忽略的是：预加载的 URL 必须和最终渲染时浏览器实际发起的请求 URL 完全一致，差一个斜杠、一个参数、甚至大小写，都会导致两次请求。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
