HTML无自动预加载机制，须用<link rel="preload">（首选，需在<head>中声明as="image"）或Image对象（适合运行时条件加载）；伪方案如display:none、loading="lazy"等均无效。
HTML 本身没有“自动预加载图片”的机制，<img> 标签无论加不加 loading="eager" 都只是按需触发下载；真要提前加载，必须用 <link rel="preload"> 或 JavaScript 的 Image 对象。
为什么 <link rel="preload"> 是首选方案
它在 HTML 解析早期就介入，不占布局、不触发渲染、不执行解码，只做一件事：告诉浏览器“这张图马上要用，请现在就取”。比 JS 创建 Image 更早、更轻、更可控。
- 必须写在
<head>里，且越靠前越好；写在<body>后或动态插入，浏览器直接忽略 -
as="image"必须显式声明，否则浏览器当普通 fetch 处理，可能跳过缓存策略或 MIME 校验 -
href值必须是静态路径（如/assets/hero.webp），不能含模板变量、JS 表达式或相对路径错误（比如 HTML 在/page/下却写./img.jpg） - 可加
fetchpriority="high"（Chrome 101+），但旧版浏览器会忽略，无副作用
Image 对象适合哪些场景
当你需要运行时判断、条件加载、或监听成功/失败状态时，Image 是唯一可靠选择。比如用户 hover 按钮后预载下一页缩略图，或根据 window.devicePixelRatio 加载 @2x 版本。
- 事件绑定必须在赋值
src之前：img.onload = () => {}再img.src = url，否则缓存命中时会错过回调 - 要检查
img.complete：若为true，说明已缓存，需立即执行成功逻辑 - 避免在循环中密集
new Image()—— 浏览器并发连接数有限（通常 6~8），建议用 Promise 队列或节流控制 - 不要长期持有
Image实例引用，尤其挂全局或闭包里；不用时可设img.src = ''辅助 GC
常见伪预加载写法，为什么不能用
很多看似“简单”的方式实际无效，甚至损害性能评分或移动端表现。
立即学习“前端免费学习笔记（深入）”；
-
<img src="xxx.jpg" style="display: none">：仍占用布局空间（即使隐藏）、触发完整渲染流程、增加主线程负担，Lighthouse 可能判为“隐藏但关键资源” -
loading="lazy"当预加载用：它是延迟加载，不是提前加载；Chrome 会推迟到滚动前 500px 才发请求，完全违背预加载意图 -
<link rel="prefetch">加图片：这是为“下一次导航”准备的，优先级低，首屏不会提前取，Network 面板显示为Priority: low -
<picture>里写loading="lazy"：该属性只对<img>生效，<source>上写了也无效
WebP/AVIF 预加载必须带 fallback
现代格式虽小，但旧浏览器不支持。预加载时如果只写 href="/hero.webp"，IE 或 Safari 13.1- 用户会白屏——因为 <link rel="preload"> 不提供降级能力。
- 必须配合
<picture>结构，在最终<img>的src中提供 JPEG/PNG 兜底 - 预加载的
href和<img>的src必须一致，否则浏览器当成两个资源，重复下载 - 服务端返回的
Content-Type必须与type属性（如type="image/webp"）匹配，否则部分浏览器可能丢弃该 preload 请求
最容易被忽略的是：预加载只改时机，不解决体积问题。一张没压缩的 2MB WebP，preload 了照样卡住首屏。真正有效的优化，永远是「精准选图 + 正确 preload + 格式压缩 + 尺寸约束」四者缺一不可。
