在实现响应式图片时，srcset和sizes这对属性组合堪称黄金搭档，但用起来也着实让不少开发者头疼。一个配置不当，轻则图片模糊，重则浪费流量，用户体验大打折扣。今天，我们就来深入聊聊这两个属性，帮你避开那些常见的“坑”。
srcset中的x描述符表示设备像素比（DPR），而非物理分辨率或CSS像素宽度；必须搭配sizes属性按渲染宽度选图，否则x描述符会失效或导致错误加载。
srcset 里写的到底是像素值还是设备像素比？
不少开发者在写 srcset 时习惯直接套用“2x”“3x”，结果在某些安卓机或高 DPI 笔记本上图片依然模糊，或者加载了远超需要的高清图。关键在于：srcset 中的 x 描述符（如 logo.png 2x）表示的是**设备像素比（device pixel ratio）**，不是屏幕物理分辨率，也不是 CSS 像素宽度。
它只在你没有提供 sizes、且浏览器无法推断渲染宽度时才起作用；一旦使用了 sizes，浏览器就会优先按 sizes 计算出目标宽度，再从 srcset 中选取最接近的源——此时 x 描述符会被忽略，必须改用 w 描述符。
srcset="a.jpg 400w, b.jpg 800w, c.jpg 1200w"→ 按 CSS 渲染宽度匹配srcset="a.jpg 1x, b.jpg 2x"→ 仅当无sizes且图片占满视口宽度时有效- 混用
w和x会触发解析错误，浏览器可能退回到第一个源
sizes 属性不写或写错，srcset 就基本白搭
sizes 不是可选项，它是让浏览器提前获知“这张图在页面中最终会渲染成多宽”的唯一可靠方式。不写 sizes，浏览器只能假设图片宽度为 100vw，导致小屏手机也去加载 1200w 的大图。
常见错误包括：写死 sizes="100vw"（无视布局断点）、漏掉媒体查询、单位用错（比如写成 500px 而非 50vw）。
- 响应式卡片内图片宽为容器的 100%，卡片在桌面端最大 300px →
sizes="(min-width: 768px) 300px, 100vw" - 全屏 banner 图 →
sizes="100vw"合理，但要注意视口缩放或横向滚动时的边界情况 - 使用 CSS 自定义属性动态控制？不行。
sizes不支持 CSS 变量，只能硬编码或通过 JS 动态设置img.sizes
怎么验证 srcset + sizes 是否真生效？
别只靠肉眼判断清晰度。打开 Chrome DevTools → Network 面板，刷新页面，筛选 Img 类型，查看每张图的 “Size” 列和 “Request Headers” 中的 Sec-CH-DPR 或 User-Agent，再比对 Initiator 是否为 img 标签本身。
- 如果始终加载同一个源（比如总是
800w），很可能是sizes写得过于宽泛，或者媒体查询条件没有命中 - Chrome 模拟器切换到 “Pixel 2” 设备后仍加载 400w 图？检查是否误将
400w当作“400 像素宽”，其实它对应的是 CSS 宽度约 200px（在 @2x 下） - Firefox 不支持
Sec-CH-DPR，但可以通过img.currentSrc在控制台实时打印，确认实际加载的是哪个源
兼容性与 fallback：IE 和旧 Safari 怎么办？
srcset + sizes 在 IE 中完全无效，Safari 早期版本也不支持 w 描述符。单纯加上 src 作为 fallback 并不足够——老浏览器会忽略 srcset，但依然发起 src 请求；而现代浏览器在有 srcset 时，src 仅作为兜底，不一定被加载。
- 必须提供合理尺寸的
src，例如src="photo-800.jpg"，对应srcset中的 800w 源，避免老浏览器拉取过大资源 - 需要支持 IE？可以用
srcset+sizes，不支持media属性匹配 - 构建时自动补充
src？Webpack 的responsive-loader或 Vite 插件可生成，但务必校验输出中src是否与最小的w源一致
最后需要提醒的是，这套机制的实际生效依赖浏览器对 sizes 的解析时机——它在 HTML 解析阶段就触发资源选择，所以 sizes 字符串不能靠 JS 注入，也不能放在 document.write 里。写错一个括号或漏个逗号，整个 sizes 就会被忽略，退化成 100vw。细节决定成败，这句话在这里再贴切不过了。
