预加载高分辨率图片需分场景：首屏关键图用<link rel="preload" as="image" fetchpriority="high">，交互型图用new Image()按需预载，srcset仅选图不改变请求时机。
预加载高分辨率图片不是“多加个 srcset 就完事”，而是要分清场景：是首屏关键图（比如 banner），还是用户交互后才需要的高清资源（比如点击放大）。策略错了，反而拖慢首屏、浪费带宽。
用 <link rel="preload"> 预载首屏高清图
这是唯一能真正提前发起请求、进缓存、不渲染、不影响布局的方式，适用于你确定这张图会在首屏立即展示且需高清晰度（如 Retina 屏下的 @2x banner）。
-
href必须指向真实存在的高清图路径（比如/images/hero@2x.webp），不能是模板字符串或未解析的变量 -
as="image"缺一不可——漏了它，浏览器当普通 fetch 处理，跳过图片专属缓存和解码流程 -
fetchpriority="high"在 Chrome 101+ 有效，能压过其他中低优先级请求；旧版忽略无副作用，建议加上 - 别和
loading="lazy"共存：一个要“提前下”，一个要“滚动前不下”，逻辑冲突，浏览器可能直接忽略 preload
用 new Image() 按需预载交互型高清图
适合 hover 缩略图时预载大图、点击弹窗前预载高清原图、或根据 window.devicePixelRatio > 1 动态决定是否拉取 @2x 版本。
- 必须先绑定
onload/onerror，再赋值src；否则缓存命中时事件同步触发，回调直接丢失 - 赋值后立刻检查
img.complete === true，为true说明已缓存，可立刻执行后续逻辑（比如显示按钮） - 避免密集调用：一次预载 5 张高清图，可能触发浏览器并发限制（通常 6~8 个），建议用 Promise.all + 限并发（如每次最多 3 个）
- 示例封装：
const preloadHiRes = (url) => { const img = new Image(); return new Promise((resolve, reject) => { img.onload = () => resolve(img); img.onerror = () => reject(new Error(`Failed to preload ${url}`)); img.src = url; });};
srcset + sizes 不是预加载，别误当“自动高清”开关
它们只告诉浏览器“从一堆图里选一张下载”，不改变请求时机。如果这张图本身是懒加载的（loading="lazy"），或者在 JS 动态插入的 DOM 里，那再高清也得等滚动到视口才发请求。
立即学习“前端免费学习笔记（深入）”；
- 首屏高清图必须删掉
loading="lazy"，否则 Lighthouse 会报“LCP 延迟”，且实际可能白屏几百毫秒 -
sizes值必须反映真实占位宽度，比如侧边栏内固定 300px 宽的图，写sizes="300px"；写成"100vw"会让手机用户误下 4K 图 -
srcset中的w描述符（如1920w）必须与原图真实像素宽一致，否则浏览器选源错乱
最容易被忽略的是：预加载高清图的前提，是服务端已生成对应尺寸和格式（WebP/AVIF）的文件。前端无法把一张 170MB TIFF “实时转成高清 WebP”——没这回事。所有 preload 或 new Image() 的 URL，都得是部署好的、经过压缩和降采样的真实资源路径。
