响应式图片核心是浏览器按视口宽度、DPR等自主选图，而非CSS缩放；仅max-width:100%无法减少下载体积，必须用srcset+sizes配对实现精准加载。
响应式图片不是靠 CSS 缩放“假装”适配，而是让浏览器从多个预生成的图片资源中，根据设备视口宽度、像素密度（DPR）、甚至网络状况，自主选择最合适的那一张加载——srcset 和 sizes 是实现这一逻辑的核心开关。
为什么只写 max-width: 100% 不够
这个 CSS 规则只能控制显示尺寸，无法改变实际下载的文件体积。小屏手机仍会下载一张 2000px 宽的 src 图片，造成流量浪费和首屏延迟。更隐蔽的问题是：高 DPR 设备（如 iPhone）用 1x 图源渲染时，浏览器会拉伸像素，导致模糊——srcset 才是解决清晰度问题的正解。
常见错误现象包括：
- 页面在手机上加载慢，Network 面板里看到大图被完整请求
- Retina 屏上文字边缘锐利但图片发虚，放大后可见明显锯齿
- 使用
background-image+background-size: cover实现“响应式”，却没做多格式或尺寸切分
srcset 的两种描述符怎么选：w 还是 x
w 描述符（基于宽度）和 x 描述符（基于像素密度）不能混用，选错会导致浏览器忽略整个 srcset 列表。
立即学习“前端免费学习笔记（深入）”；
使用场景差异：
-
w必须配合sizes使用，适用于容器宽度随布局变化的场景（比如卡片内图片占 50vw、列表项里占 100vw） -
x适合固定尺寸容器（如头像 80×80px），浏览器只看 DPR：DPR=2 就取avatar@2x.jpg，无需sizes - 现代项目中优先用
w，因为能同时适配不同视口和 DPR；x已逐渐被w+ 高宽候选覆盖
示例对比：
<img src="logo-1x.png" srcset="logo-1x.png 1x, logo-2x.png 2x" alt="logo">
<img src="hero-small.jpg" srcset="hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, (max-width: 900px) 50vw, 33vw" alt="hero">
<picture> 什么情况下非用不可
当需要的不是“同一张图的不同尺寸”，而是“不同构图”或“不同格式优先级”时，<picture> 就不可替代。
典型场景：
- 移动端裁掉背景、突出人物脸部，桌面端展示完整场景（艺术方向 Art Direction）
- 想默认用
webp，但 Safari 旧版不支持，需回退到jpg - 横屏加载宽幅图，竖屏加载竖构图图（用
media="(orientation: landscape)"）
注意：<source> 标签按顺序匹配，第一个满足条件的即生效；<img> 是兜底，必须存在且带 alt。
一个最小可用示例：
<picture> <source type="image/webp" srcset="hero.webp"> <source type="image/jpeg" srcset="hero.jpg"> <img src="hero.jpg" alt="hero image"> </picture>
容易被忽略的细节和兼容性坑
真正上线时卡住的往往不是语法，而是这些点：
-
sizes值必须是媒体查询 + 宽度单位（vw、px），不能写100%或auto，否则浏览器无法计算显示宽度 - 所有
srcset中的图片必须有真实存在的宽高比一致性，否则height: auto会失效，引发布局偏移（layout shift） - Webpack/Vite 构建时若未配置图片处理插件，
srcset里的路径可能 404——别只在本地测试 - Safari 对
srcset+sizes的支持从 v18.0 开始才稳定，iOS 17.4+ 用户基本无感，但 iOS 16 及更早需检查 fallback 行为
最常漏掉的一环：没有给 <img> 设置 width 和 height 属性。即使用了 srcset，显式声明原图宽高仍能防止 CLS（累积布局偏移），这是 Core Web Vitals 的硬指标。
