Chrome DevTools 中查看 srcset 实际加载图片：打开 Network 面板刷新页面，找到 img 请求，查看 Headers → Request Headers 中的 dpr 和 viewport-width 字段，结合 sizes 计算目标宽度，再匹配 srcset 中最接近的 w 值；也可直接查看 img.currentSrc 或右键“Open image in new tab”确认。
Chrome DevTools 里怎么看 srcset 实际选了哪张图
打开 Network 面板，刷新页面，找到对应 <img> 请求，点开看 Headers → Request Headers。关键看两个字段：dpr（设备像素比）和 viewport-width（视口宽度）。浏览器就是靠这两个值 + sizes 计算出“当前该用多宽的图”，再从 srcset 列表里挑最匹配的 w 项。
常见误判点：
- 没写
sizes时，浏览器默认按100vw算，哪怕图片只占 300px 宽，也可能加载 1920w 图 -
sizes="(max-width: 768px) 100vw"缺少兜底值，Safari 13.1 之前会 fallback 到100vw，导致桌面端也加载移动端图 - CSS 强制设了
width: 100%，但父容器没设宽，sizes就算不准——浏览器看到的是“理论上可能撑满”，不是“实际渲染多宽”
IE 和旧版 Safari 对 srcset 的支持底线在哪
srcset 在 IE 全系完全不支持；Safari 从 9.1 开始支持 w 描述符，但直到 10.1 才稳定支持 sizes + w 组合；iOS Safari 9.3 有 srcset 但存在解析 bug，比如把 photo-800w.jpg 800w 当成无效项跳过。
所以真实兼容策略是：
立即学习“前端免费学习笔记（深入）”；
- 必须保留
src属性作为降级：它不是可选的，是所有不支持srcset的浏览器唯一能读到的图源 - 别指望 IE 用户能拿到响应式图——要么用
<picture>+<source>配 polyfill（如 picturefill），要么直接放弃，让 IE 加载中等尺寸图 - 如果目标用户含 iOS 9.x，避免在
srcset里混用w和x，旧 Safari 解析器容易卡住，只认纯w或纯x列表
为什么手机上还是加载了 1200w 的图
根本原因不是 srcset 写错了，而是浏览器“以为”这张图要显示得很大。它根据 sizes 算出渲染宽度，再匹配 srcset 中最接近的 w 值。如果算出来是 950px，而你只提供了 400w 和 1200w，它只能选后者。
排查要点：
- 用 Chrome DevTools 的 Elements 面板选中
<img>，右键 → “Scroll into view”，然后看右下角显示的实际渲染宽度（Layout 标签页里也能查） - 检查是否用了
em/rem写sizes——这些单位在计算时依赖字体大小，极易失准，只推荐vw、px和媒体查询 - 确认所有
srcset条目后都带w（如photo-800.jpg 800w），漏掉单位会被整个忽略 - 避免在
sizes里写死固定像素值（如sizes="800px"），除非你 100% 确保图片容器在所有断点下都严格等于这个宽
用 picture + source 做艺术指导时怎么验证 fallback 是否生效
<picture> 的核心逻辑是“顺序匹配，一命中就停”。如果第一个 <source media="(max-width: 768px)"> 匹配了，后面的 <source> 和最终的 <img src="fallback.jpg"> 就全被跳过。
验证方法很直接：
- 手动改浏览器宽度，观察 Network 面板里加载的是哪个 URL；切到 769px 以上，确保加载的是 desktop 版本
- 临时删掉第一个
<source>，刷新——这时应该立刻 fallback 到<img src>指定的图，否则说明<img>缺失或路径错 - 注意
<source>的media是 CSS 媒体查询语法，不支持 JS 表达式或自定义函数，写min-width: 769px就行，别加括号外的空格
真正难的不是写法，是预估各断点下图片的渲染宽度——模拟器常报错，得拿真机连 DevTools 调试。比如 iPad Pro 的“桌面模式”下 viewport-width 可能报 1024，但实际渲染宽度受 Safari 缩放影响，可能只有 800px。
