关键在于让浏览器在正确时间、用正确尺寸、加载正确分辨率的图片，三者缺一不可；仅靠max-width:100%无法解决性能问题，必须配合srcset+sizes、响应式背景图、语义化图片选择及懒加载等综合策略。
关键不是“让图片变小”，而是让浏览器在正确时间、用正确尺寸、加载正确分辨率的图——三者缺一不可。
为什么只加 max-width: 100% 还不够
它只解决缩放变形问题，不解决性能问题。一张 4MB 的大图即使被 CSS 缩到 200px 宽，仍会完整下载、解码、渲染，拖慢首屏。
- 常见错误现象：
img标签没配srcset，但开发者以为“CSS 自适应了就 OK” - 移动端用户实际下载了桌面端用的 1920w 图片，流量浪费 + 解码卡顿
-
width: 100%比max-width: 100%更危险：它强制拉伸小图，导致模糊+重绘 - 必须搭配
height: auto，否则宽高比断裂，object-fit也救不回来
srcset + sizes 必须成对出现
单独写 srcset，浏览器只能靠猜测选图；sizes 才是告诉它“这张图在你屏幕上实际占多宽”。漏掉 sizes，等于白写 srcset。
- 错误写法：
<img src="fallback.jpg" srcset="s.jpg 480w, m.jpg 768w" alt="如何用CSS优化响应式图片的页面性能" >→ 浏览器默认按 100vw 猜，大概率选错 - 正确写法：
<img src="fallback.jpg" srcset="s.jpg 480w, m.jpg 768w, l.jpg 1200w" sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw" alt="如何用CSS优化响应式图片的页面性能" > -
sizes值必须真实反映布局：如果图片在 768px 断点下占容器 1/3 宽，就不能写50vw - 服务端若支持 Client Hints（如
Width,DPR），可省去sizes计算，但需后端配合
背景图响应式不能靠 background-size: cover 单干
background-image 不支持 srcset，所以单写一条 URL 就等于全设备加载同一张图——高清屏模糊，小屏浪费带宽。
立即学习“前端免费学习笔记（深入）”；
- 必须用
@media查询分条件加载：@media (min-width: 768px) { .hero { background-image: url(img/hd.jpg); } } - 高 DPR 设备要叠加判断：
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) - 组合写法顺序很重要：先写通用图，再写
768px + 2x的组合规则，否则会被覆盖 - 语义化图片（如内容图、图标）坚决不用背景图，优先走
<picture></picture>+srcset
懒加载 loading="lazy" 是把双刃剑
它只控制加载时机，不控制加载哪张图。如果 srcset 配得不对，懒加载反而让错误尺寸的图更晚暴露问题。
- 必须和
srcset+sizes同时使用，否则移动端可能懒加载出 desktop 尺寸图 -
loading="lazy"对首屏图片无效（浏览器自动取消 lazy），别给首屏图加 - 滚动触发前，
<img alt="如何用CSS优化响应式图片的页面性能" >无尺寸会导致布局抖动，务必提前设好aspect-ratio或容器padding-top占位 - 背景图懒加载需 JS 配合
IntersectionObserver，纯 CSS 无法实现
最易被忽略的一点：所有响应式图片优化都建立在「容器尺寸可预测」前提下。如果父容器宽高由 JS 动态计算或 CSS Grid / Flex 异步撑开，sizes 和 object-fit 都可能失效——这时得退回到 JS 驱动的图片加载逻辑。
