<link rel="preload">是唯一可靠方式，需在<head>中声明as="image"、路径与CSS中url()完全一致，并按响应式条件加media属性匹配，避免滥用和缓存失效。
用 link rel="preload" 提前加载全屏背景图
浏览器默认不会为 background-image 提前加载 CSS 中定义的图片，哪怕它占满整个视口。必须显式告诉浏览器“这张图很重要，马上 fetch”。link rel="preload" 是唯一可靠方式，且需搭配 as="image" 和正确的 media 条件（比如只预加载大屏用的图）。
- 写在
<head>里，放在 CSS 引入之前更稳妥 - 路径必须和 CSS 里
url()中完全一致（含相对路径、CDN 域名、查询参数） - 如果背景图响应式切换（如
@media (min-width: 768px)），对应预加载也要加media属性匹配 - 不要滥用：只对首屏必现、尺寸大（>100KB）、无 JS 控制逻辑的图预加载
CSS 里 background-image 要配合 background-size: cover 和 background-position
预加载只是把图拉下来，渲染效果还得靠 CSS 控制。全屏背景常见问题是拉伸变形或留白，关键在三个属性组合：
-
background-size: cover—— 等比缩放填满容器，可能裁剪边缘 -
background-position: center center—— 确保焦点区域居中（比如人脸、主体物） -
background-repeat: no-repeat—— 防止平铺干扰全屏感 - 容器本身需设
height: 100vh或min-height: 100vh，否则背景高度塌陷
避免预加载失效的典型错误
很多写了 preload 却没提速，问题常出在细节不匹配：
- CSS 里写的是
url("/img/hero.jpg?v=2")，但link的href漏了?v=2→ 浏览器当两张不同图处理，重复请求 - 用了
as="fetch"或漏掉as属性 → 不触发图片解码优化，甚至被降级为普通 fetch - 在
display: none的元素上写背景图，又给它预加载 → 图下了但根本不用，纯浪费带宽 - 服务端开了强缓存（
Cache-Control: max-age=31536000），但预加载时加了时间戳参数 → 缓存失效，失去意义
要不要用 fetchpriority="high"？
Chrome 101+ 支持 fetchpriority，但对 preload 无效 —— 它只作用于 <img> 或 <iframe>。想影响预加载优先级，只能靠 rel="preload" 本身（浏览器已将其视为最高优先级资源之一），无需额外加这个属性。强行加上反而可能被忽略。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的是：预加载的图如果尺寸远超设备物理像素（比如 4K 图给手机加载），会吃光内存、拖慢渲染。上线前务必检查实际设备下的 network 面板，确认预加载的 URL 和最终应用的 URL 完全一致，且尺寸合理。
