图片压缩后台显示“已生成手机版”，手机打开产品页却仍然很慢，先别继续降低画质。需要核对浏览器实际选中了哪一个文件，以及图片服务是否真的返回了对应尺寸。模板里出现srcset，只能证明提供了候选声明，不能证明这一轮请求用了合适的资源。
把一次选图记录拆成四个数值和一个地址
在目标手机宽度下重新打开页面，记录视口宽度、设备像素比、图片显示宽度、实际文件像素尺寸，以及图片元素的currentSrc。再从网络面板核对该地址的响应状态、传输字节和缓存情况。
MDN对currentSrc的说明明确指出，它表示浏览器选中的图片地址，和图片是否成功加载无关。因此读到地址后还要看请求及解码是否成功。也不要只盯着HTML里的src：使用srcset时，src未必就是本次选中的候选。
区分选图过大和文件本身过重
假设教学页面的图片显示宽度为360个CSS像素，设备像素比为2，约720像素宽的资源可以作为清晰度预算的起点。这不是强制浏览器执行的公式；候选分布、缩放和浏览器策略都会影响选择。不能因为手机屏幕小，就断定超过360像素的图一定浪费。
- 显示槽位被高估：实际只占半栏，sizes却提示占满视口，先修正布局提示。
- 中间候选缺失：只有很小与很大两档，先检查是否需要生成合适的中间尺寸。
- 请求地址对，文件尺寸不对：图片服务可能忽略了缩放参数，或缓存键没有区分变换条件。
- 尺寸合适，字节仍大：再评估编码格式、压缩质量和图片内容复杂度。
第三种尤其值得单独验证。把各候选文件实际下载下来，查看真实像素尺寸和文件哈希。不能只根据文件名里有“720”就认定它是720像素宽，也不能把同一个原图改几个名字当成多尺寸交付。
给模板团队和图片服务团队同一份样本
光算的srcset与currentSrc排查方法详细解释了槽位、候选尺寸与缓存对测试的影响。协作时可以围绕一个明确产品页，交付“实际显示宽度—sizes声明—选中URL—返回文件尺寸”的对照，避免两边都只检查自己那一半。
模板团队负责解释断点、栏宽与候选声明；图片服务团队负责解释变换结果及缓存规则。若桌面和手机使用不同裁切，先明确这是构图切换，不要把不同画面的图片误当成单纯的分辨率梯度。
复测要换初始条件，不能只拖窄窗口
先在大窗口加载再缩小，浏览器不一定重新下载小图。应在目标视口和设备像素比下新建浏览上下文或明确清理相关缓存后重新导航，并保存这次请求的记录。冷缓存结果和已缓存结果分开报告，两者回答的问题不同。
修复之后同时检查画质。铭牌、接口边缘和产品纹理如果已经无法辨认，即便体积很小也不算合格。页面中的关键参数最好有对应的可读文字，不让买方只能放大图片猜数字。最终结论应是哪些页面、哪些条件下选图与文件结果正确；没有实际测量整页性能，就不要把图片字节下降直接写成Lighthouse分数或转化率提升。