HTML5无专用预加载标签，但可用<link rel="preload" as="image">（最标准）或JS Image对象（运行时控制）实现；禁用display:none伪预加载和prefetch（不适用图片）。
HTML5 本身没有专门的 <img> 预加载语义标签，但有多个可靠、现代且被广泛支持的方式实现图片预加载——关键看你要预加载的时机和控制粒度。
用 <link rel="preload"> 提前获取关键图片
这是最标准、最可控的 HTML5 原生方案，适用于你明确知道某张图片将在首屏或关键交互中立即用到（比如 banner 背景图、首帧头像）。
它让浏览器在解析 HTML 早期就发起请求，不阻塞渲染，也不触发解码，比 JS 创建 Image 对象更早、更轻量。
-
as="image"必须指定，否则浏览器可能忽略或降级为fetch优先级 -
fetchpriority="high"可选，进一步提示重要性（Chrome 101+ 支持） - 路径必须是绝对或相对于当前页面的合法 URL；相对路径不能以
//开头（会被当成协议缺失） - 不支持动态生成的 URL，也不能带 JS 表达式
<link rel="preload" as="image" href="/assets/hero-banner.jpg"> <link rel="preload" as="image" href="/avatars/user-123.png" fetchpriority="high">
用 JavaScript 的 Image 对象手动预加载
适合需要运行时判断、按条件加载、或加载大量非关键图片（如相册下一页缩略图）的场景。兼容性极好，所有浏览器都支持。
立即学习“前端免费学习笔记（深入）”；
注意：它不会自动插入 DOM，只是下载并缓存；但若图片已存在于缓存，onload 会同步触发，需做好状态管理。
- 务必设置
img.src后再绑定onload/onerror，否则可能错过事件 - 避免重复创建相同
src的Image实例，可加简单缓存 Map - 大批量预加载时建议节流或分批，防止瞬时并发过多请求（尤其在弱网下）
const preloadImage = (url) => {
return new Promise((resolve, reject) => {
const img = new Image();
img.onload = () => resolve(img);
img.onerror = () => reject(new Error(`Failed to load ${url}`));
img.src = url; // ⚠️ 这行必须在绑定事件之后、之前设置
});
};
preloadImage('/assets/thumb-01.jpg').then(() => console.log('loaded'));
避免用 <img> + opacity: 0 或 display: none 预加载
这种“伪预加载”方式看似简单，实则问题很多：它会占用布局空间（即使隐藏）、触发完整渲染流程、增加主线程负担，还可能被 Lighthouse 判定为“隐藏但关键资源”，影响性能评分。
更严重的是，在某些移动端 WebView 中，display: none 的 <img> 可能被延迟加载甚至跳过解码，导致后续显示时仍要解码，失去预加载意义。
- 不要给预加载用的
<img>加loading="lazy"—— 它会彻底阻止加载 - 不要依赖 CSS 隐藏来“静默”加载；浏览器对不可见元素的资源调度策略越来越激进
- 如果真要用 DOM 方式，至少用
<img decoding="async">减少解码阻塞
<link rel="prefetch"> 不适合图片预加载
很多人混淆 preload 和 prefetch。prefetch 是为「将来可能导航到的页面」准备资源，优先级极低，通常在空闲时才下载，且可能被浏览器丢弃。它对当前页图片无实际加速作用。
如果你的目标是让用户点击按钮后立刻显示下一张图，prefetch 大概率赶不上——它不保证下载完成时间，也不保证缓存命中率。
-
rel="prefetch"适合预取下一页面的 JS/CSS，不是图片 - Chrome 已将
prefetch降级为 best-effort，Firefox 默认禁用 - 想稳妥控制图片加载节奏，还是回到
preload或 JSImage
真正要注意的是：预加载不是越多越好。每个多余的 preload 都会抢占主资源带宽，尤其在 3G 或低端设备上反而拖慢首屏。只对用户「接下来 1 秒内必然看到」的图片做预加载，其余交给自然加载或懒加载即可。
