Network面板是唯一可靠验证手段，需禁用缓存、切换设备/缩放观察实际请求URL及Content-Length，并检查srcset语法、sizes媒体条件覆盖和w值区间匹配。
怎么在本地快速验证 srcset + sizes 是否按预期选图
浏览器开发者工具的 Network 面板是唯一可靠手段，不能靠肉眼“看起来清晰”就认为生效。关键看实际发起请求的图片 URL 是否匹配你预设的断点逻辑。
操作步骤：
- 打开 DevTools → Network → 过滤
img - 在 Device Toolbar 中切换不同预设设备（如 iPhone SE、Pixel 5、MacBook Pro），或手动缩放视口宽度
- 刷新页面，观察加载的是哪张图（比如
hero-400w.jpg还是hero-1200w.jpg） - 右键该请求 → Copy → Copy response headers，检查
Content-Length是否与对应尺寸图的实际体积吻合（防缓存干扰）
注意：Chrome 的 “Network Conditions” 里勾选 “Disable cache” 是必须的；Safari 需关闭 “Disable Cache” 才能触发真实选图逻辑（它默认缓存 srcset 决策结果）。
为什么在 Chrome 模拟器里看到 2x 图，但真机上还是加载了 1x
因为模拟器强制设置 devicePixelRatio，而真机受系统缩放、浏览器 zoom、甚至某些安卓定制 ROM 的 DPI 覆盖影响，2x 描述符只在无 sizes 且图片占满视口时才起作用——这种场景在现代响应式布局中几乎不存在。
立即学习“前端免费学习笔记（深入）”；
真正决定加载哪张图的是 sizes 算出的渲染宽度 + srcset 中的 w 值。如果你混用了 2x 和 800w，整个 srcset 会被浏览器忽略，直接回退到 src。
排查要点：
- 检查控制台是否报错
Failed to parse 'srcset' value - 确认
sizes值是媒体条件 + 长度单位（vw/px），不是%或rem - 用
getComputedStyle(img).width在 Console 里实测图片当前渲染宽度，再比对sizes表达式是否覆盖该值
如何构造可复现的跨设备兼容性测试用例
不要依赖随机截图或用户反馈。最小化测试用例必须固定三要素：srcset 列表、sizes 表达式、CSS 布局约束。例如：
<img src="fallback.jpg"
srcset="cat-400w.jpg 400w, cat-800w.jpg 800w, cat-1200w.jpg 1200w"
sizes="(max-width: 400px) 100vw, (max-width: 800px) 50vw, 33vw"
style="width: 100%; max-width: 400px;">这个例子明确暴露问题点：
- 小屏（≤400px）应加载
cat-400w.jpg，但如果父容器有padding未计入，实际渲染宽度可能超 400px，导致加载cat-800w.jpg - iOS Safari 15.4 之前版本不支持
sizes中的calc()，写sizes="calc(100vw - 40px)"会直接失效 - Android WebView 67+ 才完整支持
w描述符，旧版会降级为src
测试时优先覆盖 Chrome 120+、Safari 16.6+、Firefox 115+，这三个版本已覆盖全球 95% 有效流量。
最容易被忽略的兼容性陷阱：sizes 的默认值和 fallback 行为
sizes 不写，浏览器默认按 100vw 计算；写了但媒体条件没覆盖当前视口，就会用最后一个无条件值（即逗号末尾那个）。很多人写 sizes="(min-width: 768px) 300px"，漏掉默认项，结果在桌面端反而加载了 100vw 对应的大图。
更隐蔽的问题是：当 sizes 计算出的宽度是 320px，而 srcset 只有 400w 和 800w，浏览器会选择 400w —— 它只找「不小于」所需宽度的最小项，不会插值或缩放判断。这意味着你必须保证 srcset 中的 w 值覆盖所有 sizes 可能产出的宽度区间，尤其要注意移动端视口缩放后 CSS 像素宽度变化（如 iOS Safari 横屏时 100vw 可能变成 375px 而非 414px）。
