是唯一能在html解析早期触发请求的方式，而loading="eager"仅表示不懒加载、解析到该标签时才发起请求，无法抢占带宽窗口；二者本质不同：前者预加载（提前下载），后者仅取消懒加载（按时下载）。
必须用 <link rel="preload">，且只用于首屏确定会立即使用的图片；其他方式要么无效，要么不可控。
为什么 <img loading="eager"> 不等于预加载
浏览器默认把所有 <img> 当作 Medium 优先级，哪怕加了 loading="eager" 或 decoding="async"，它也只是“不懒”，不是“提前”。解析到该标签时才开始请求，错过 HTML 解析早期的带宽窗口。首屏大图如果写在 DOM 较后位置（比如 banner 在 <main></main> 里），就真会被拖慢。
-
loading="eager"是默认行为，显式写上无额外收益 -
decoding="async"只影响解码线程，不影响下载时机和优先级 -
fetchpriority="high"仅对 Chromium 112+ 有效，且需配合src存在；若同一张图已用<link rel="preload">声明，则此属性被忽略
<link rel="preload" as="image"> 的硬性要求
这是唯一能在 HTML 解析头部阶段就触发请求的方式，但配置错就白搭。
-
as="image"必须写，缺了浏览器无法设置正确的请求头（如Accept: image/webp）和缓存策略 - 必须放在
里，越靠前越好；放在中可能被忽略或延迟 -
href路径必须准确：相对路径基于 HTML 文档位置，不是 JS 执行位置；别写./assets/hero.jpg却把页面部署在/user/下 - 不支持动态值：
href="/assets/${name}.webp"这类模板语法会被当字面量请求，直接 404 - WebP 图片建议配
type="image/webp"，但 fallback（如 JPG）需由 CSS 或 JS 控制，<link>本身不处理格式降级
什么时候该用 new Image() 而不是 <link rel="preload">
只有两种情况值得动 JavaScript：需要运行时判断，或资源路径无法静态声明。
- 用户 hover 某个卡片后预加载下一页详情图
- 根据
window.devicePixelRatio动态选@2x版本 - 轮播组件中，第一张已渲染，第二张需在第一张显示后立刻就位
关键操作顺序不能错：先绑定 onload/onerror，再赋值 src。否则缓存命中时事件同步触发，回调直接跳过。还要检查 img.complete，为 true 就说明已就绪，得立刻走成功逻辑。
并发控制很重要：浏览器对同源图片请求有上限（通常 6–8 个），循环里密集 new Image() 会导致排队阻塞，建议用 Promise.allSettled + 限流（例如每次最多 4 个）。
常见踩坑点
最容易被忽略的是「重复加载」和「优先级稀释」。
- 给一张图既写
<link rel="preload">又在 DOM 里放<img src="...">，且路径不完全一致（比如一个带 query 参数?v=2，一个没带），浏览器会当成两个资源，重复下载 - 把非首屏图也全
preload，挤占真正关键资源的带宽，Lighthouse 反而报“避免预加载非关键资源” -
loading="lazy"和<link rel="preload">同时用——逻辑矛盾，浏览器可能忽略 preload 或降级优先级 - CSS 背景图无法被 HTML 解析器发现，必须手动
<link rel="preload">，否则首屏 Hero 区域会闪一下才出图
验证是否生效，打开 Chrome DevTools → Network → 右键表头勾选 Priority，目标请求应显示 Highest；同时看 Timing 里的 Start Time 是否远早于对应 <img> 标签的解析时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
