背景图加载失败时页面不留白，元素仍保留尺寸并显示透明或底色；而img加载失败会显示带×的缺省占位框，若未设宽高则尺寸为0×0，易导致布局塌陷。
背景图加载失败时页面是否留白
用 background-image 时，如果图片 404 或路径错误，元素本身还在，但背景区域直接变透明——用户看到的是空盒子或底色，不会出现撕裂图标。而 img 标签加载失败会渲染一个带“×”的缺省占位框，且默认尺寸为 0×0（除非设了 width/height），可能造成布局塌陷、文字上移。
实际开发中容易踩的坑是：给 div 加了 background-image 却没设 height，结果什么也看不到；或者用 img 时漏写 alt 和宽高，导致 SSR 渲染后首屏抖动。
- 背景图必须确保父容器有明确
height（哪怕是min-height） -
img建议始终声明width和height，避免回流 - 关键内容图（如产品主图、logo）不用
background-image，否则加载失败即信息丢失
响应式场景下 background-size 与 srcset 的行为差异
background-size: cover 或 contain 是 CSS 层面的缩放控制，不改变原始图片文件请求；而 img 的 srcset 是让浏览器根据设备像素比和视口宽度，主动选择不同分辨率的资源发起请求——这是真正的响应式资源加载。
比如一个 banner 区域在桌面端需要 1920×600 的图，移动端只需 750×300，用 background-image 就得靠媒体查询切不同 CSS，维护成本高；用 img 配合 srcset + sizes，一行 HTML 就能交由浏览器自动决策。
-
background-image的响应式依赖@media+ 多套 CSS 规则，易冗余 -
srcset支持w描述符（如image-2x.jpg 2w），picture还支持type切格式（AVIF/WebP/JPG 回退） - 背景图无法通过 JS 动态切换源（
element.style.backgroundImage = 'url(...)'可行但无缓存/预加载机制）
DOM 可访问性与 SEO 影响不可逆
img 标签天然携带语义：alt 属性供屏幕阅读器朗读，搜索引擎可索引图片文件名、alt 文本、周围上下文。而 background-image 完全脱离 DOM 内容流，对爬虫和辅助技术不可见——哪怕你用 ARIA 标注，也无法替代原生语义。
这不是“加个 aria-label 就行”的问题。W3C 明确建议：任何承载信息、影响理解的图像，必须用 img；仅作装饰、无信息量的才用背景图。线上常见反例：用 background-image 实现按钮图标却不提供文本替代，导致键盘用户无法识别操作目标。
- 广告图、产品图、数据图表类必须用
img，否则违反 WCAG 1.1.1 - 角标、分隔线、渐变蒙层等纯视觉修饰可用
background-image - 不要为了“减少 DOM 节点数”而把内容图硬塞进背景——可访问性权重远高于这点性能损耗
首屏关键图像必须阻塞 HTML 解析吗
是的，img 在 HTML 解析阶段就触发请求，属于“关键资源”；background-image 要等 CSSOM 构建完成才开始加载，天然延迟。这意味着：首屏核心图（如登录页 banner、文章封面）用 img 更可靠——它参与浏览器的关键渲染路径，可被 preload 提前拉取；而用背景图，即使加了 preload，也受限于 CSS 加载时机，弱网下可能白屏更久。
但反过来，非首屏模块（如页脚推荐图、折叠面板内的图）用背景图 + loading="lazy"（对 img）或 IntersectionObserver（对背景图）更合理，避免初始请求过多拖慢 TTFB。
- 首屏内重要内容图优先用
img，配合fetchpriority="high"和decoding="async" - 背景图适合做“锦上添花”，尤其当它和动画、滤镜等强样式耦合时
- 真正难处理的是“既需语义又需复杂定位”的场景（如带遮罩的文字配图）——这时应拆解：文字+
img+ 伪元素遮罩，而非强行用背景图塞所有
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
