写了srcset仍下载大图：用currentSrc查清浏览器选了谁

写了srcset，手机仍下载大图，先读取图片元素的currentSrc，再对照实际显示宽度、sizes和设备像素比。srcset只是候选集合；浏览器还需要知道图片预计占多宽。sizes与布局不符、像素密度较高，或测试沿用了先前缓存，都可能让选图结果与直觉不同。

srcset列资源，sizes描述槽位

采用宽度描述符时，480w表示源图自身宽度为480像素，不是让它在页面上显示480个CSS像素。候选描述必须与真实文件相符。sizes说明在不同条件下，图片预计占用多宽的显示槽位；它不会替代CSS给元素定宽。

MDN响应式图片文档说明浏览器会结合屏幕大小、像素密度、缩放等条件选择资源，并按sizes中首个匹配的媒体条件确定槽位提示。写成100vw意味着提示图片占满视口；如果桌面实际只占一半栏宽，这个提示可能高估所需资源。

<img src="/images/gear-720.webp"
  srcset="/images/gear-360.webp 360w,
          /images/gear-720.webp 720w,
          /images/gear-1200.webp 1200w"
  sizes="(max-width: 600px) calc(100vw - 48px),
         560px"
  width="1200" height="800"
  alt="齿轮组件正面">

这里假设手机左右各留24像素、桌面图槽固定560像素。你的网站如果有侧栏、网格间距或不同断点，就不能原样照搬。sizes中的长度必须合法，不能把百分比宽度直接当作槽位值写入；视口相对长度与百分比不是同一个概念。

别看src猜结果，读取currentSrc

MDN的currentSrc说明给出了读取当前选中图像URL的方法。src可能只是后备地址，Elements里看到它仍是大图，不能证明浏览器真的下载了这张。等待图片完成后，在控制台读取目标元素：

const img = document.querySelector('img.product-main');
console.log({
  currentSrc: img.currentSrc,
  slotWidth: img.getBoundingClientRect().width,
  viewport: window.innerWidth,
  dpr: window.devicePixelRatio
});

选择器要换成实际图片，不要误查站点Logo。再去Network核对请求URL、响应尺寸、传输与缓存信息。currentSrc能告诉你选了谁，不能单独证明请求成功；图片破损时还应看完成状态、HTTP响应及解码错误。也不要仅凭naturalWidth反推源文件像素，它可能受密度校正等因素影响。

小屏下载较大候选，不一定选错

CSS像素与图像像素不是同一回事。假设图片显示宽360个CSS像素、DPR为2，准备约720像素宽候选是合理的起点。这是像素预算示例，不是要求浏览器每次机械执行同一公式；缩放、可用候选和浏览器策略也会影响选择。若只有360与1600两档，浏览器可能没有恰当的中间资源。

排查时不要先把所有高分辨率图片删掉。产品细节和标识可能确实需要清晰度。先让候选梯度匹配常见槽位，再比较实际传输成本与画质。格式和压缩质量解决的是另一层问题：选图正确，也可能每张候选编码过重；选图错误，单纯转WebP仍可能浪费带宽。

缩小浏览器窗口不是完整复测

先在大窗口加载图片再缩小，浏览器未必为节省少量字节重新换下较小候选。为验证选择规则，应在目标视口和DPR下新开上下文，明确缓存设置后重新导航。记录当次currentSrc，不把拖动窗口后的显示大小当成网络重新选择的证据。

本地演示采用两个独立浏览器上下文，保留各自的视口、DPR、槽位和选中地址。这个执行结果证明示例规则下的实际选图，不能代表所有浏览器、设备或网络。你的正式模板应另外覆盖横竖屏、浏览器缩放和真实手机；移动端模拟有帮助，但不能代替所有设备回归。

光算谷歌SEO服务包含网站代码优化和移动端适配方向，响应式图片的模板检查与开发配合可按项目确定。交付时保留“哪个视口实际选中了哪个URL”的记录，比只说“已启用响应式图片”更容易复核。

模板改了，候选文件也要验

先从图片处理服务或本地生成目录核对实际像素宽度，确认文件并非同一张大图改了三个名字。若缩略图服务忽略尺寸参数，HTML看似提供多档资源，网络实际仍取回同样大的内容。候选描述符与真实文件必须一致，不能为了让浏览器选小图，把大文件随意标成小宽度。

图片外层若有内边距、边框和网格间距，实际图槽会比容器或视口更窄。本地示例就把这些空间算进sizes，并从元素矩形读回实际宽度。项目中可以先在关键断点测量，再将稳定的布局规则写进模板。不要反过来不断修改CSS，让错误的sizes看上去成立。

如果元素被隐藏或还没进入最终布局，读取到的宽度可能暂时为零或并非最终值。先确认组件已完成该状态的布局，再测矩形；同时保留初始HTML中的sizes，避免只看到脚本修改后的结果。某个断点特别异常时，把媒体条件的先后顺序也列入检查，宽泛条件写在前面可能提前匹配。

最后留一张文字清楚、边缘细节可判断的产品图做画质对照。减小候选尺寸后若参数标识已经模糊，就应重新选择分辨率或把重要说明移为可读HTML，而不是只追求更小的字节数。

不同裁切和首屏预加载还要分开查

如果手机要展示竖版、桌面用横版，这是美术方向问题，可用picture与source明确不同媒体条件下的素材，不能只把不同构图混进同一组宽度候选。候选图保持同一内容和比例更容易预留空间；跨断点更换比例时，应另外安排稳定布局。

对LCP主图，检查预加载选择是否与最终img一致，避免预加载桌面大图后手机又请求另一张。具体加载顺序见首屏图片lazy与LCP排查。如果HTML模板、图片处理服务与CSS由不同团队维护，应让三方共享槽位规则和真实候选尺寸。