srcset中w描述符必须配合sizes才能生效，否则浏览器无法感知图片布局宽度而退化为x匹配；sizes需真实反映CSS计算后的盒模型宽度，单位必须合法且覆盖所有断点，缺一不可。
srcset 里的宽度描述符（w）必须配合 sizes 才能生效
浏览器不会自动猜你页面里图片占多宽，srcset 中用 w 描述符（比如 1200w）时，必须配 sizes 告诉它“在不同视口下这张图实际渲染多宽”。否则浏览器只能退化成按设备像素比（x 描述符）选图，失去响应式布局感知能力。
常见错误是只写 srcset 不写 sizes，或者 sizes 值写死（比如 sizes="100vw"）但实际图片被 CSS 限制了宽度，导致选图偏大、浪费带宽。
-
sizes的值是媒体条件 + 宽度的组合，比如sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px" - 每个媒体条件匹配时，对应后面的宽度就是浏览器计算 srcset 的基准（可以是
vw、px、em） - 不写媒体条件时，最后一项是默认值，必须存在
- 如果 CSS 动态改变了图片容器宽度（比如 sidebar 展开），
sizes不会自动重算——得用 JavaScript 更新sizes属性
sizes 的宽度值不是图片原始尺寸，而是它在页面中的布局宽度
很多人把 sizes 当成“想让图片显示多大”，其实它是告诉浏览器：“这张图在当前布局下，盒模型宽度是多少”。这个值要和 CSS 实际作用后的宽度一致，否则选图偏差可能高达 2–3 倍。
例如：一个图片放在 max-width: 600px 的卡片内，在桌面端它最多占 600px；但卡片本身在 1200px 宽屏里只占一半，那 sizes 就不该写 600px，而该写 50vw 或更精确的 (min-width: 1200px) 50vw, 100vw。
立即学习“前端免费学习笔记（深入）”；
- 用 Chrome DevTools 的 “Layout” 面板确认图片的 computed width，再反推
sizes表达式 - 避免用
width: 100%+max-width这种组合直接套进sizes——它不是简单等价关系 - 如果图片用
object-fit: cover或被父容器overflow: hidden裁剪，sizes仍按盒模型宽度算，不是可见区域宽度
srcset 用 w 描述符时，浏览器按密度无关方式选图
当 srcset 含 w 描述符（如 "photo-400w.jpg 400w, photo-800w.jpg 800w"），浏览器会先根据 sizes 算出当前需要的布局宽度（比如 320px），再找最接近且不小于它的源（比如 400w），而不是按 DPR 查表。这更适合现代响应式布局。
对比 x 描述符（如 "photo@1x.jpg 1x, photo@2x.jpg 2x"）：它只认设备像素比，无法适配不同宽度容器，也不支持 art direction（换图）。
-
w描述符必须和sizes成对出现，缺一不可 - 所有
srcset中的w值应覆盖你sizes可能产出的所有宽度，否则可能 fallback 到src - 工具如 Responsive Image Breakpoint Generator 可帮你生成合理
srcset列表，但输出的sizes仍需人工校验
Chrome 的 Network 面板里看实际加载的是哪张图
别靠肉眼或设备尺寸猜，打开 DevTools → Network → 刷新 → 点击图片请求 → 看 Headers 里的 Request URL，这才是真实加载的资源。同时注意响应头是否有 Content-Length 差异，验证是否真省了流量。
容易忽略的点：本地开发时用 file:// 协议，部分浏览器会禁用 srcset 切换逻辑；必须起本地服务（如 python3 -m http.server）才能测准。
- 在 Device Toolbar 里切换尺寸后，要硬刷新（Ctrl+Shift+R），否则缓存可能掩盖问题
- 如果发现总是加载最大图，先检查
sizes是否为100vw且没写媒体条件，再查 CSS 是否意外撑开了容器 - 某些 CDN 或图片服务（如 Cloudflare Images）会改写
srcset，导致本地测试和线上行为不一致
sizes 往往比 srcset 更难写对——它依赖你对布局的精确理解，而不是图片本身的分辨率。多数人卡在这一步，不是不会写语法，是没意识到它和 CSS 盒模型的强耦合。 
