图片预加载本质是用提前触发HTTP请求，而非依赖渲染时机；需注意路径、缓存一致性、优先级及解码优化。
图片预加载的本质是提前触发HTTP请求
浏览器不会因为你在HTML里写了 <img alt="如何使用HTML完成图片预加载设置" > 就立刻下载图片——它得等元素进入渲染流程、甚至进入视口才可能发起请求。预加载的关键，是让图片资源在页面其他部分还在解析时，就悄悄发出去请求，不阻塞主流程，也不依赖DOM插入时机。
最直接有效的方式不是操作 <img alt="如何使用HTML完成图片预加载设置" > 标签本身，而是用 <link rel="preload"> 告诉浏览器：“这个资源我马上要用，现在就去拿”。
常见错误：把 <img src="a.jpg" loading="eager" alt="如何使用HTML完成图片预加载设置" > 当作预加载——loading="eager" 只是取消懒加载，并不等于预加载；它仍需等该 <img alt="如何使用HTML完成图片预加载设置" > 元素被解析并准备渲染，时机晚于 <link rel="preload">。
<link rel="preload"> 必须指定 as="image"
如果不加 as 属性，浏览器无法判断资源类型，就不会设置正确的请求头（比如 Accept: image/webp,*/*），可能导致服务端返回非最优格式，甚至 406 错误。
立即学习“前端免费学习笔记（深入）”；
正确写法示例：
<link rel="preload" href="/assets/banner.webp" as="image" fetchpriority="high">
fetchpriority="high" 是可选但推荐的，它向浏览器明确该请求优先级高于普通资源（注意：仅 Chromium 115+ 支持，Safari 和 Firefox 忽略）。
注意事项：
-
href必须是绝对路径或根相对路径（如/assets/），不能是文档相对路径（如../images/），否则预加载会失败且无提示 - 不要对同一张图写多个
<link rel="preload">，重复请求不会被自动去重 - 预加载的图片必须与后续实际使用的
<img src alt="如何使用HTML完成图片预加载设置" >完全一致（含查询参数），否则缓存不会复用
JavaScript 动态预加载适合条件化场景
当图片路径由用户行为、设备特征（如 DPR）、或A/B测试决定时，静态 <link> 不够用，需要用 JS 创建 Image 实例触发请求。
关键点不是“创建对象”，而是“赋值 src”——只要给 new Image().src 赋一个有效URL，浏览器就会发起请求：
const img = new Image();<br>img.src = '/assets/photo@2x.jpg'; // 请求立即发出<br>// 不需要 append 到 DOM，也不需要监听 onload
但要注意：
- 避免在循环中密集创建
Image实例，可能触发浏览器并发请求数限制（通常为6个/域名），建议节流或按需触发 - 如果图片带 cookie 认证，确保
Image实例的请求携带凭证：用fetch()+createObjectURL()替代，或设置img.crossOrigin = 'use-credentials' - 动态预加载无法享受
<link rel="preload">的早期解析优势（它发生在 HTML parser 阶段），JS 执行总在解析完成后
验证是否真的预加载成功
打开 Chrome DevTools → Network 面板，刷新页面，筛选 media 或 img 类型，看目标图片是否出现在列表顶部、Timing 中的 Start Time 是否早于 DOMContentLoaded 时间点。
更可靠的判断方式是看 Initiator 列：
- 显示
parser：来自<link rel="preload">，符合预期 - 显示
other或脚本文件名：来自 JS 的new Image()，时机稍晚 - 显示
img元素：说明只是普通渲染加载，没走预加载
容易被忽略的一点：预加载只管“发请求”，不管“解码”。即使图片已下载完成，首次 <img alt="如何使用HTML完成图片预加载设置" > 渲染时仍可能卡顿——这是图像解码耗时，需配合 decoding="async" 或使用 WebP/AVIF 缩小体积来缓解。
