loading="lazy"对background-image完全无效，因其仅支持src属性的html元素（如），而css背景图由样式引擎解析，浏览器无法预判加载时机。
loading="lazy" 对 background-image 完全无效
浏览器原生的 loading="lazy" 属性**不支持任何 CSS 引用的图片**，包括 background-image、border-image、伪元素 ::before/::after 中的 content: url()，以及所有通过 CSS 变量或 @import 引入的图片资源。这是规范层面的限制，不是写法问题，也不是浏览器兼容性问题。
为什么 background-image 无法用 loading="lazy"
原因很直接：loading 是 HTML 元素属性，只作用于能携带 src（或 srcset）的标签，比如 <img> 和 <iframe></iframe>。而 background-image 是纯样式行为，由 CSS 引擎解析，浏览器在解析 HTML 阶段根本不知道它会加载什么图——更谈不上预判视口位置、设置加载时机。
- 即使你给带
background-image的<div> 加上 <code>loading="lazy"，该属性会被忽略（HTML 解析器不认识它对该元素的意义） - Chrome DevTools 的 Network 面板里，这类背景图请求始终出现在初始加载阶段，不会随滚动延迟
- 试图用
content-visibility: auto包裹背景图容器，也只能跳过渲染，**不能阻止 background-image 的 fetch 请求**（除非配合display: none或移除 class） - 把
<div style="background-image: url(...)"> 替换为 <code><img src="..." loading="lazy" alt="">，再用 <code>position: absolute; object-fit: cover; width: 100%; height: 100%填满父容器 - 确保
<img>父容器有明确宽高（或 aspect-ratio），否则loading="lazy"在 Safari 等浏览器中可能静默失效 - 若需多图响应式（类似
picture+srcset），必须把srcset和sizes写在<img>上，且二者必须同时存在，缺一不可 - 避免在父容器上使用
transform、opacity、will-change—— 这些会干扰浏览器对滚动容器的判定，导致懒加载不触发 - 用
IntersectionObserver监听目标元素进入视口，然后动态添加含background-image的 class 或内联 style - 注意：不要在
onload后立刻 remove observer，要显式调用unobserve()，否则 React/Vue 列表项频繁更新时易内存泄漏 - 服务端渲染（SSR）场景下，首屏背景图建议直接输出，非首屏区域可返回空占位或骨架结构，等客户端 JS 接管后再注入样式
- 别依赖
visibility: hidden或opacity: 0来“隐藏”背景图——这些不阻止请求，只是让图不可见
替代方案：用 img + object-fit 模拟背景图懒加载
如果必须实现“视觉上是背景图、行为上可懒加载”，唯一可靠路径是改用 <img> 标签，并用 CSS 覆盖定位和裁剪。这不是 hack，而是目前最接近原生懒加载语义的实践。
真要加载 CSS 背景图？只能靠 JS 或服务端控制
如果你无法改动 DOM 结构（比如 CMS 输出固定 HTML + CSS），那 background-image 的延迟加载只能交由 JavaScript 主动控制，没有原生捷径。
background-image 换成 <img> 就万事大吉，却忘了检查父容器是否用了 overflow: hidden 或嵌套在 <iframe></iframe> 里——这两种情况都会让 loading="lazy" 失效，而且毫无报错。
