浏览器原生srcset+sizes是最可靠轻量的响应式图片方案，无需框架或JS，自2014年起全面支持；错误使用sizes会导致小屏加载大图或桌面模糊，<picture>仅适用于art direction和格式降级。
浏览器原生的 srcset + sizes 就是当前最可靠、最轻量的“新方法”——它不需要框架、不依赖 JS，且自 2014 年起已稳定支持所有现代浏览器。所谓“新”，其实是很多人还没用对，或被封装组件带偏了方向。
为什么别急着写自定义图片组件
硬套 React 或 Vue 的“响应式图片组件”，往往绕过浏览器预加载逻辑：HTML 解析阶段，<img> 已发起请求；而 JS 渲染的 wrapper 要等 DOM Ready 才能注入 src，首屏图片必然延迟加载甚至 FOUC。
- 自定义组件若未透传
srcset和sizes到底层<img>，等于主动放弃浏览器选图能力 - 多数 UI 库（如 Ant Design、Chakra UI）的
Image组件默认只做懒加载和 fallback，不生成sizes，需手动补全 - Next.js 的
<Image>确实自动注入，但仅限其 SSR/SSG 场景；静态导出（output: 'export'）时会退化为普通<img>，sizes丢失
sizes 写错是最常见的性能黑洞
sizes 不是“最大宽度”，而是“浏览器渲染时这张图大概占多宽”。写错直接导致小屏加载 2000w 图、桌面端却用 480w 图模糊显示。
- 错误写法：
sizes="50vw"→ 浏览器无视媒体条件，永远按 50% 视口宽计算 - 正确写法：
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" - 若父容器有
max-width: 600px且居中，sizes必须匹配该约束，例如：(max-width: 600px) 100vw, 600px - 用 rem 单位？不行。
sizes只认vw、px、em（且em基于根字体大小），30rem会被当作无效值 fallback 到100vw
什么情况下才真该用 <picture>
<picture> 不是 <img> 的升级版，它是为两个明确场景存在的：美术裁剪（art direction）和格式降级（format fallback）。其他情况用它反而增加复杂度和维护成本。
立即学习“前端免费学习笔记（深入）”；
- 换构图：移动端用竖版特写，桌面端用横版全景 →
<source media="(max-width: 768px)" srcset="portrait.jpg"> - 格式优先级：想发
image/avif，不支持就跳过，再试image/webp，最后image/jpeg→<source srcset="photo.avif" type="image/avif"><source srcset="photo.webp" type="image/webp"> - 必须把
<img>放在<picture>最末尾，且带src和alt；漏掉就完全不渲染 -
<source>顺序不能错：宽泛条件（如(min-width: 400px)）必须放后面，否则高 DPR 设备永远匹配不到后面的高清规则
真正容易被忽略的是：即使你写了完美的 srcset 和 sizes，如果父容器没设 max-width: 100% 或用了固定像素宽（如 width: 800px），图片照样无法缩放。CSS 层的容器约束和 HTML 层的资源选择，必须同步生效才算完整响应式。
