sizes缺失导致srcset形同虚设，因浏览器无布局上下文无法匹配w描述符，只能回退加载src或空白；w必须配sizes，x仅适用于固定宽高场景，且二者不可混用。
srcset 和 sizes 不是“锦上添花”，而是现代响应式图片的底线配置。只写 src 或仅靠 max-width: 100% 的 CSS，等于把带宽和清晰度全交给运气。
为什么 sizes 缺失会导致 srcset 形同虚设
浏览器看到 srcset="photo-400w.jpg 400w, photo-800w.jpg 800w" 后，根本不知道这张图在页面里会占多宽——它没有布局上下文。没有 sizes，浏览器无法把「视口宽度 × 设备像素比」映射到「400w / 800w」这些值上，只能放弃智能选择逻辑。
实际表现是：
- Chrome、Firefox 多数情况下 fallback 到加载
src指定的图（或第一个候选） - Safari iOS 11–12.0 可能完全不触发
srcset逻辑，图片空白 - DevTools Network 面板里永远只看到
src对应的请求，误以为“生效了”
验证是否真起作用，别看渲染效果，直接查 img.currentSrc（需等 load 事件后读取），或在 Network 面板加 Filter：largeresources 看是否意外拉了 1200w 图。
w 描述符必须配 sizes，x 描述符可以不配但场景极窄
w 是为流式布局服务的：banner、文章配图、网格项……只要图片宽度随容器变化，就必须用 w + sizes。这时 sizes 不是样式控制，而是提前声明“这张图在不同断点下**将渲染成多宽**”。它必须和真实 CSS 布局对齐：
立即学习“前端免费学习笔记（深入）”；
- CSS 是
width: 100%; max-width: 600px;→sizes="(max-width: 600px) 100vw, 600px" - Grid 中占 1/3 宽，断点从 768px 开始 →
sizes="(max-width: 768px) 100vw, 33.33vw" - 导航 logo 移动端占满屏宽、桌面端固定 200px →
sizes="(max-width: 480px) 90vw, 200px"
x 描述符（如 1x, 2x）只适用于固定宽高的元素，比如头像、图标、按钮内嵌图。它绕过布局宽度，只看设备像素比（DPR）。但注意：
-
srcset中不能混用w和x，例如"icon.png 1x, photo.jpg 800w"整个属性会被浏览器丢弃 -
1.0x或2.0x不被识别，必须写整数1x/2x -
src仍是必需 fallback，尤其对 IE 或旧 Android WebView
<picture> 不是替代品，而是解决 srcset 无能为力的两类问题
当你要做这两件事时，<picture> 才是唯一正解：
- 艺术方向（Art Direction）：移动端需要裁剪竖构图，桌面端用横幅大图。CSS 缩放做不到内容级裁剪，必须换源
-
格式回退（Format Fallback）：优先加载
image.webp，但 Safari 13 之前不支持 WebP，得 fallback 到image.jpg
关键细节：
- 所有
<source>必须写在<img>标签之前，顺序错就失效 -
<source>的media属性要和真实 CSS 断点一致，别写(max-width: 768px)却在 CSS 里用@media (max-width: 767px) -
<img>的sizes仍要写，且反映它在对应<source>生效条件下的实际渲染宽度 - 不要用
<picture>去替代简单分辨率适配——它更重，解析开销更大，且部分 CDN 会忽略<source>缓存策略
容易被忽略的三个实操细节
真正上线后出问题的，往往不是语法错误，而是这些隐性约束：
-
sizes是字符串，不支持calc()、CSS 变量或百分比单位（如50%），写50vw或400px才合法 - 生成的图片尺寸建议按 1.5× 步进（如
320w,480w,768w,1200w），覆盖 iPhone SE 到 4K 屏的逻辑像素宽度，避免浏览器被迫选大一号 - 路径全部用相对路径，且以 HTML 文件所在目录为基准；混用
./images/和images/在构建工具或子路由下极易 404
最麻烦的不是写错，而是写对了却没生效——因为 sizes 值和实际 CSS 布局宽度不一致，或者 CDN 缓存了旧版 HTML 而你本地已更新。
