CSS响应式背景图该用cover还是contain更合适？

cover会切掉关键内容，因其按宽高比缩放至短边填满容器、长边必然溢出并被隐藏，易误切人脸、标题或按钮，需配合background-position和固定容器尺寸规避。

background-size: cover 什么时候会切掉关键内容

cover 的目标是“填满容器”，不是“显示全图”。它按原图宽高比缩放，直到短边触达容器边界，长边必然溢出——溢出部分被隐藏。这在 banner、视觉主导的卡片上很常见，但容易误切人脸、标题或按钮。

常见错误现象：background-size: cover 用在带左上角文字的卡片上，结果文字区域只剩天空；横屏切竖屏后关键内容突然消失；没设 background-position，默认居中导致操作区偏出可视范围。

1. 必须搭配 background-repeat: no-repeat，否则重复平铺时裁剪逻辑失效
2. background-position 只能挪动整张缩放后的图，不能“锁定头部”或“对齐按钮”
3. 父容器若没设明确 width 和 height（比如 height: auto），cover 就失去参考系，图可能缩在左上角不动
4. 移动端小屏下裁剪区域重算剧烈，建议真机验证，别只靠 DevTools 模拟

background-size: contain 为什么四周总有白边

contain 的目标是“整张图必须可见”，所以它缩放至长边刚好触达容器边界，短边自然留空——这不是 bug，是守约行为。白边位置由 background-position 决定，默认 center，可改用 top left 把图压到左上角对齐内容。

典型误用：background-size: contain 被当成“自动放大”用在横幅上，结果图缩成邮票大小；或容器又宽又高（比如大屏侧边栏），图缩得极小，破坏视觉权重。

1. 若容器尺寸远大于图片原始尺寸，需配合 min-width/min-height 或媒体查询兜底
2. 误设 background-repeat: repeat 会导致留白区平铺缩放后的图，铺不满的部分仍被裁——这几乎从来不是想要的效果
3. 当容器宽高比接近图片比例时，白边会变少甚至消失，但无法保证完全消除

cover 和 contain 的缩放倍数怎么算

两者都不拉伸变形，缩放倍数是确定性计算，本质是数学取舍：

1. cover：缩放倍数 = max(containerWidth / imageWidth, containerHeight / imageHeight)
2. contain：缩放倍数 = min(containerWidth / imageWidth, containerHeight / imageHeight)

也就是说，cover 看谁更“卡不住”，contain 看谁先“顶到头”。实际项目中，如果原始图是 1920×1080，容器是 300×200，cover 倍数 ≈ 1.5（1080→200），contain 倍数 ≈ 0.156（300→1920）——差距近 10 倍，视觉效果天差地别。

既要关键内容可见，又不能留白，怎么办

cover 和 contain 都不满足时，硬套只会让问题更隐蔽。比如电商商品图要始终显示 logo 和价格标签，又不能裁也不能留白，这时纯 CSS 缩放已失效。

1. 服务端生成多尺寸图，前端用 <picture> + srcset 匹配不同 DPR 和视口，精度远超 CSS 缩放
2. 对重要图像标注焦点区域（如 Adobe Subject Area），再用 JS 读取并动态计算 background-position 偏移
3. IE9 以下不支持这两个值，若还要兼容，得降级为固定尺寸图或滤镜 hack
4. 移动端尤其注意：4K 图配 cover 会触发额外解码和内存占用，加载慢 + 渲染卡顿，建议源图 ≤ 2× 容器最大尺寸

真正棘手的不是选哪个值，而是意识到：当设计要求同时满足“100%可见”“无留白”“不裁剪”时，cover 和 contain 已经不是选项，而是信号——该换方案了。