<link rel="preload" as="image">是首屏高清图唯一合理选择，因其在HTML解析早期抢跑下载，不依赖DOM构建，且需确保href与img src完全一致、as属性正确、配合fetchpriority="high"提升优先级。
直接用 <link rel="preload"> 声明高清图，配合 fetchpriority="high" 和精确路径，是提速最有效的方式；JavaScript 的 new Image() 仅适合按需加载（比如用户 hover 后预载下一页），别用它扛首屏。
为什么 <link rel="preload"> 是首屏高清图的唯一合理选择
浏览器解析 HTML 是线性的，等它读到 <img src="product-2x.jpg"> 才发起请求，此时可能已错过关键渲染窗口。而 <link rel="preload" as="image"> 在 <head> 阶段就抢跑下载，不依赖 DOM 构建，也不受 CSS 加载阻塞。
-
as="image"必须写全，写成as="img"或漏掉会退化为普通 fetch，Network 面板里 Priority 显示为 Low -
href必须与后续<img>的src完全一致（包括大小写、斜杠、查询参数），否则缓存不命中，等于白 preload -
fetchpriority="high"在 Chrome 101+ 有效，能压过字体、CSS 等资源的默认优先级，旧版忽略无副作用 - 不能动态拼接路径，
href="/images/${sku}-2x.webp"这类模板语法会被当字面量请求，404
new Image() 什么时候该用、怎么用才不翻车
它只适合“运行时判断是否加载”的场景：比如用户鼠标悬停商品卡片时，才预载对应详情页的高清图；或根据 window.devicePixelRatio 决定加载 @2x 还是 @3x 版本。
- 必须先绑定
onload/onerror，再赋值src，否则缓存命中时事件同步触发，回调直接跳过 - 要检查
img.complete === true，true 表示已缓存，需立刻执行成功逻辑 - 避免循环里密集
new Image()，浏览器并发请求数通常卡在 6~8 个，建议用 Promise.allSettled 控制并发数（例如每次最多 3 个） - 不要把
img挂到全局变量或闭包里长期持有，加载完后可设img.src = ''辅助 GC
WebP/AVIF 高清图预加载必须加 fallback
你写了 <link rel="preload" href="p123.webp" as="image">，但用户用 Safari 15 或老版 Edge，.webp 根本不支持——这时候页面里 <img src="p123.jpg"> 仍会发起第二次请求，带宽和时间双浪费。
立即学习“前端免费学习笔记（深入）”；
- 要么用
<picture>+<source type="image/webp">统一管理源，然后对主 fallback 格式（如.jpg）做 preload - 要么只 preload 兼容性最强的格式（如
.jpg），高清格式靠srcset在运行时协商，不强求 preload - 别在同一个页面既 preload WebP 又在
<img>里写 JPG 路径，这是典型的“自废缓存”操作
最容易被忽略的是路径一致性：preload 的 href 和最终 <img> 的 src 差一个点、一个斜杠、甚至大小写不同，缓存就失效。这点在微前端或静态资源托管路径不统一的项目里尤其致命。
