现场是这样的。文章配图用了 srcset 加三个宽度，但没写 sizes，浏览器默认按 100vw 选择。移动端实际显示宽度 360px，却下载了 1440px 的版本，单页图片体积多出 1.8MB。
中间走过弯路，把「没有用 device pixel ratio 做二次裁剪」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。sizes 缺省时按 100vw 计算，媒体查询里的实际宽度被忽略；图片在桌面端被限制在 720px 容器里，srcset 却按全屏算；CSS 里给图片设了 max-width 实际显示宽度被容器压缩。
第一件事是看实际选中的图片地址
document.querySelector('img').currentSrc补上准确的 sizes
<img srcset="a-480.webp 480w, a-960.webp 960w" sizes="(max-width:720px) 100vw, 720px">服务端按请求宽度出图
location ~* /img/(.*)-([0-9]+)\.webp$ { image_filter resize $2 -; }复测移动端图片总字节
curl -s -A 'Mozilla/5.0 (iPhone)' https://www.example.com/post/1 | grep -c 'sizes='中间停过一次，把已经改的东西回滚干净，再重新来一遍。
恢复的判定其实很直接。补上 sizes 后移动端首屏图片体积从 2.1MB 降到 620KB，LCP 提前 1.3 秒，体验分涨了 9 分。
srcset 不带 sizes 等于白做，浏览器只能按视口宽度猜，写清楚每档断点的实际宽度才是关键。报错文案容易误导，真正的原因往往在相邻那一层的日志里。