应优先使用 w 单位而非 x：w 对应图片固有宽度，配合 sizes 才能精准匹配渲染需求；x 仅在图片占满视口时可靠，现代 CSS 布局下易失效。
srcset 里写 w 还是 x，取决于你控制的是什么
写 1x、2x 是告诉浏览器“这张图专为某设备像素比准备”，但它只在图片占满视口（或你没写 sizes）时才可靠生效；现代响应式布局中，图片宽度由 CSS 控制，x 描述符容易失效。更稳妥的是用 w 单位——它对应图片的固有宽度（比如 400w 表示这张图原始宽 400 像素），配合 sizes 才能真正匹配渲染需求。
常见错误：
- 混用
400w, logo-2x.png 2x→ 整个srcset被忽略，回退到src - 只写
srcset="img-2x.jpg 2x"没配sizes→ 小屏手机也加载 2x 图，浪费带宽 -
src指向 1920w 大图 → 老浏览器直接卡顿，且无降级缓冲
sizes 必须和 CSS 布局真实一致，不能靠猜
sizes 不是“建议”，而是浏览器计算加载哪张图的唯一依据。它声明的是“这张图在当前视口下会渲染多宽”，单位必须是 vw、px 等合法长度，不能是 % 或 rem。
例如这个写法：sizes="(max-width: 768px) 100vw, 50vw"，意思是：
立即学习“前端免费学习笔记（深入）”；
- 视口 ≤ 768px 时，图片占满整个视口宽（比如 iPhone SE 的 375px 视口 → 需要约 750w 图）
- 视口 > 768px 时，图片只占视口一半（比如 1200px 视口 → 需要约 600w 图）
但如果实际 CSS 把图片设为 width: 300px，而 sizes 还写 100vw，浏览器就会去选 1200w 图——哪怕你根本用不上。
验证是否生效，只看 Network 面板里的实际请求
别信“看起来清晰”，也别靠模拟器缩放判断。真正在意的是浏览器到底发了哪个请求：
- 打开 DevTools → Network → 过滤
img - 勾选
Disable cache（Chrome）或关闭Disable Cache（Safari） - 切换设备预设（如 iPhone 12、iPad Pro），或手动拖动视口宽度
- 刷新页面，看加载的是
hero-400w.jpg还是hero-1200w.jpg - 右键请求 →
Copy response headers→ 对照Content-Length确认没被缓存干扰
如果始终只加载 src 指向的图，检查控制台是否报错 Failed to parse 'srcset' value，或 sizes 里有没有漏掉单位（比如写了 sizes="50" 而不是 sizes="50vw"）。
src 是 fallback，不是可选项
src 属性必须存在，且应指向一个体积适中、清晰度够用的版本（比如 768w 或 800w）。原因有二：
- IE、旧版 Safari、部分 Android WebView 完全不支持
srcset，此时只有src生效 - 某些低版本 WebView 会解析失败并静默丢弃整个
srcset，src是唯一兜底
别把 src 设成最小图（比如 320w），否则老设备用户看到的就是模糊图；也别设成最大图（比如 2560w），否则首屏加载直接受拖累。
最易被忽略的一点：即使你写了完美的 srcset 和 sizes，只要 src 缺失或路径 404，整张图在不支持的环境里就彻底消失——连 alt 文字都不会显示。
