<link rel="preload"> 是唯一可靠且不干扰渲染的高清壁纸预加载方式；其他方法如 loading="lazy"、display: none 的 <img> 或 CSS background 均存在延迟加载、优先级低、触发 layout 或无法监听等问题。
直接用 <link rel="preload"> 声明高清壁纸路径，配合 fetchpriority="high" 和正确的 as="image"，是唯一既可靠又不干扰渲染的预加载方式；其他“伪预加载”（比如 display: none 的 <img> 或 CSS background）要么失效、要么拖慢首屏。
为什么不能用 loading="lazy" 或 display: none 的 <img>
这两类做法常被误当作预加载，实际效果相反或不可控：
-
loading="lazy"是推迟加载——哪怕你加在首屏<img>上，Chrome 仍可能等到滚动前 500px 才发请求，壁纸根本来不及显示 -
<img src="wallpaper.jpg" style="display:none">看似“提前下载”，但浏览器不会提升其优先级，它和普通资源一样排队，且可能被 Lighthouse 标为“阻塞渲染的非关键图片” - CSS
background: url(...)+position: absolute; top: -9999px更糟：它会触发 layout、占用内存、无法监听是否加载成功，且 WebP fallback 几乎无法控制
<link rel="preload"> 必须写对这四点
高清壁纸体积大、解码耗时，预加载必须精准声明，否则浏览器可能降级处理或忽略优先级：
-
as="image"缺一不可——不写会导致请求头缺失Accept: image/webp,*/*，WebP 资源无法正确协商 -
href必须是绝对路径或根相对路径（如/assets/wallpaper@2x.webp），不能带 JS 模板变量，也不能依赖当前 JS 执行上下文 -
fetchpriority="high"对 Chrome 109+ 有效，能确保它排在普通图片之前；旧版忽略无副作用，建议保留 - 必须放在
<head>最早位置——越晚插入，浏览器开始下载的时间就越晚，对首屏壁纸意义不大
WebP 高清壁纸必须配 fallback，且不能只靠 <picture>
预加载本身不支持格式回退，<link rel="preload"> 只能指定一个 href。所以你要么：
立即学习“前端免费学习笔记（深入）”；
- 只预加载 WebP（推荐）：
<link rel="preload" as="image" href="/assets/wallpaper.webp" fetchpriority="high">，然后在真实<img>或<picture>中用<source type="image/webp">+<img src="wallpaper.jpg">做运行时 fallback - 不预加载 WebP，改用 JPEG fallback 路径预加载（牺牲体积优势）——不推荐，尤其对 4K 壁纸，JPEG 体积可能翻 3 倍
- 别试图用 JS 动态判断
supportsWebP后再new Image()预加载——时机太晚，首屏已开始渲染，用户已经看到空白或 placeholder
JS 创建 Image 对象只适合二级场景
如果你的壁纸要根据用户操作切换（比如点击“换一张”后预加载下一张），才用 JS 控制：
- 先绑定
onload/onerror，再赋值src，否则缓存命中时事件直接同步触发，回调丢失 - 检查
img.complete === true，如果是，立刻执行后续逻辑（比如替换 DOM 中的src） - 避免一次 new 多个
Image——浏览器并发限制通常为 6~8 个，高清壁纸单张就占一个连接，建议用 Promise 队列控制（例如每次最多 2 个） - 别把
img挂到全局或长期闭包里，加载完后设img.src = ''可辅助 GC
真正影响壁纸“秒出”的不是加载快慢，而是浏览器能否在渲染第一帧前就把解码好的位图准备好；<link rel="preload"> 提供了唯一可控的入口，其余所有绕道方案，都会在某个环节丢掉优先级、缓存策略或加载状态反馈。
