优先用w单位+sizes，仅图片固定尺寸时用1x/2x；混用会忽略x部分，sizes必须与CSS渲染宽度一致且带单位，否则浏览器退至100vw计算导致选错图。
srcset里写1x/2x还是w单位？先看图片是否固定尺寸
固定尺寸（比如 logo 宽 120px、按钮图标宽 24px）就用 1x/2x/3x；否则一律用 w 单位 + sizes。混用但没配对，浏览器会忽略 x 部分——不是 bug，是规范行为。
常见错误：srcset="banner@2x.jpg 2x" 配给 banner 图，结果小屏也加载大图。因为 banner 渲染宽度不固定，浏览器根本不用 2x，只当 fallback 处理。
-
1x/2x/3x只在没写sizes时生效，且仅依据window.devicePixelRatio选源 -
w单位必须配sizes，否则浏览器退回到100vw计算，大概率选错 - iPhone 15 Pro 的
devicePixelRatio是 3，但屏幕宽度才 430px —— 别按“手机=2x”硬配，要按实际 DPR
srcset + sizes 怎么写才不白写
关键不是“写了”，而是 sizes 值必须和 CSS 实际渲染宽度一致。浏览器拿 sizes 算出“这张图当前该显示多宽”，再从 srcset 中挑最接近的 w 值。差一点，就可能多下 300KB。
例如：卡片内图片 CSS 设为 max-width: 300px，但 sizes="(max-width: 768px) 100vw"，视口 1200px 时浏览器按 1200px 算，选了 1200w 图——哪怕它最终只显示 300px 宽。
立即学习“前端免费学习笔记（深入）”；
-
sizes必须带单位：50vw合法，50无效 - 断点要覆盖真实布局：如果 CSS 在
481px–768px区间设为width: 400px，sizes就得有对应项，不能只写(max-width: 480px)和768px - 兜底值建议显式写：
sizes="(max-width: 480px) 100vw, (min-width: 481px) 400px, 400px"，避免旧 Safari fallback 行为
为什么加了 srcset 还是加载最大图？检查这三点
不是代码写错，而是浏览器没拿到足够信息做判断。打开 DevTools → Network → 点开图片请求，看 Request Headers 里有没有 Sec-CH-DPR 或 Width —— 没有说明响应式逻辑根本没触发。
-
src属性缺失：老浏览器直接不显示图，现代浏览器 fallback 到空src，控制台报net::ERR_INVALID_URL -
srcset里的文件路径 404：构建工具（如 Vite）默认不自动补@2x后缀，得靠插件或手动配resolve.alias -
sizes值过于保守：比如只提供800w和1200w，但sizes算出来是 225px，浏览器只能硬选800w—— 得补一张320w或400w
picture 元素什么时候非用不可
当需要换构图、换比例、换格式，而不是单纯换分辨率时，<picture> 是唯一解。比如移动端用竖版特写图，桌面端用横版全景图；或者优先加载 webp，降级到 jpg。
注意：<source> 不支持 alt，所有可访问性描述仍由最后的 <img> 承担；media 只处理宽度/方向等媒体查询，min-resolution 已被主流浏览器弃用，别写。
-
<source>按顺序匹配，第一个满足media+type的生效，其余跳过 -
<source>的srcset仍需配合自己的sizes（如果用了 w 单位） - 邮件客户端、老旧 IE 会忽略整个
<picture>，所以内部<img>的src和alt必须存在
<canvas> 或自绘图形，window.devicePixelRatio 必须参与 canvas 缩放计算，否则再高清的 @2x 图也救不了模糊的线条。单靠 srcset 只解决了一半问题。 
