sizes属性计算逻辑是先根据字符串和视口宽度算出图片显示宽度，再从srcset中选最接近且不小于该宽度的源；必须与CSS真实布局对齐，不可写死或混用w/x描述符。
sizes属性的计算逻辑不是“写多少就用多少”
浏览器不会直接拿 sizes 里写的像素值去加载对应尺寸的图片，而是先算出图片在当前视口下的「显示宽度」（display width），再从 srcset 中挑一个最接近且不小于该宽度的源。这个过程依赖两个关键输入：你写的 sizes 字符串、当前视口宽度。
常见错误是把 sizes 当成固定宽高写死，比如：sizes="100vw" —— 这在全屏图片时没问题，但若图片实际只占栅格 1/3 宽，浏览器仍会按 100vw 计算，结果加载远大于需要的图。
- 必须和真实 CSS 布局对齐：如果某断点下图片容器 CSS 是
width: 33.33%，那sizes就得写"(max-width: 768px) 100vw, 33.33vw"，而不是照搬设计稿标注的“768px 断点下显示 256px” -
sizes是字符串，不支持calc()，也不接受 CSS 变量，写@media (min-width: var(--md))会直接让整条规则失效 - 媒体查询语法要严格：旧版 Safari 和 Edge 对空格敏感，
(max-width: 768px)中的空格会导致解析失败，必须写成(max-width:768px)
srcset里用w还是x？别混着来
srcset 必须统一用 w 描述符（如 "small.jpg 480w"）或统一用 x 描述符（如 "small.jpg 1x"），混用会直接导致浏览器跳过整个 srcset，退化为只加载 src。
选 w 更可控，因为它绑定的是图片原始宽度，配合 sizes 能做精准匹配；x 仅反映设备像素比（DPR），无法应对不同布局下图片显示宽度变化的问题——比如同一台 iPhone 在横竖屏下图片显示宽度差一倍，但 DPR 都是 3x。
立即学习“前端免费学习笔记（深入）”；
- 用
w时，每个源必须标明自身宽度，如"hero-480.jpg 480w, hero-800.jpg 800w" - 用
x时，必须确保所有source或img的srcset都有对应密度标注，否则 Retina 屏可能仍加载 1x 图 - Safari 12.1 之前版本对
w支持不全，若需兼容 iOS 12.0 及更早，得加 fallbacksrc并验证降级行为
断点值不能抄参数表，得看布局崩坏点
所谓“真断点”，是你页面内容开始错位、换行突兀、卡片挤叠、文字撑出容器的那个宽度，不是手机型号列表里的 375px 或 414px。
Chrome DevTools 的 Toggle device toolbar 拖动宽度滑块时，眼睛盯着布局变化临界点，记下那个值（比如 623px），再向上取整到好维护的数（如 640px、900px），避免边界陷阱。
- 图片相关断点尤其要结合容器行为：如果栅格系统在 768px 下从三列变两列，那
sizes里的媒体查询也得是(max-width:768px)，而不是(max-width:767px) - flex 容器没设
min-width: 0时，图片可能拒绝缩放，导致max-width: 100%失效，这时sizes算得再准也没用 - 用
em写断点（如48em）比像素更可靠，前提是根字体没被 JS 强制重设；否则反而更不稳定
picture元素不是srcset的升级版，它解决的是不同问题
当你要的不是“同一张图的不同分辨率”，而是“完全不同的构图或格式”，才必须用 <picture>。比如手机裁人脸、桌面展全景，或强制用 type="image/avif" 并提供 WebP 降级。
<source> 的 media 属性断点必须和真实 CSS 布局断点一致，顺序不能错——<source> 必须写在 <img> 之前，否则整个结构被忽略。
- 每个
<source>的srcset若含2x，必须对应标注media="(min-resolution: 2dppx)"或类似条件，否则高 DPR 设备可能加载错源 -
type="image/webp"的<source>若浏览器不支持，会跳过，落到下一个<source>或最终<img>，所以 fallback 必须存在且手动验证过加载效果 - 旧版 EdgeHTML 解析
sizes时，媒体查询里有空格会直接失效；Safari 对w描述符的支持直到 12.1 才稳定——这些都不是写了就能跑通的事
