<picture>用于多维度响应式图片适配，通过<source>按media条件（如屏幕宽度、DPR、格式）匹配首个满足项并加载对应图片，必须覆盖全断点、type与服务端Content-Type一致，且末尾<img>为强制回退；srcset+sizes适用于仅需分辨率或布局宽度适配的轻量场景，sizes须精确匹配CSS渲染宽度，避免误载大图。
用 <picture> 配合 <source> 按屏幕宽度切换图片
直接用 <img> 的 srcset 能应付简单分辨率适配，但要按设备类型（比如手机/平板/桌面）、像素密度（1x/2x）、甚至横竖屏切换完全不同的图片（比如手机端裁剪过的竖构图、桌面端宽幅横构图），必须用 <picture>。它本质是“图片容器”，内部用多个 <source> 提供候选，浏览器按条件匹配第一个满足的，再加载对应 srcset 或 src。
常见错误是把所有 <source> 的 media 写成互斥但留了间隙，比如只写了 (max-width: 480px) 和 (min-width: 768px)，中间 481–767px 就 fallback 到 <img>，容易漏掉小平板；另一个坑是 <source> 的 type 声明了 image/webp，但旧浏览器不支持，没提供 fallback 格式。
-
<source>的media必须覆盖所有可能宽度，推荐用max-width递进写法：(max-width: 480px)→(max-width: 768px)→(max-width: 1024px) - 每个
<source>的srcset可以列多个尺寸，用逗号分隔，例如"small.jpg 1x, small@2x.jpg 2x" -
<img>标签必须存在且放在<picture>最后，它的src是最终 fallback，alt也只写在这里
<picture> <source media="(max-width: 480px)" srcset="mobile-portrait.jpg 1x, mobile-portrait@2x.jpg 2x"> <source media="(max-width: 768px)" srcset="tablet-landscape.jpg 1x, tablet-landscape@2x.jpg 2x"> <source media="(min-width: 769px)" srcset="desktop-wide.jpg 1x, desktop-wide@2x.jpg 2x"> <img src="fallback.jpg" alt="描述文字"> </picture>
用 srcset + sizes 让浏览器按视口宽度选图
如果只是同一张图的不同分辨率版本（比如缩略图、中图、大图），不需要换构图，<img> 自带的 srcset 和 sizes 更轻量。关键在 sizes：它告诉浏览器“这张图在不同断点下会占多宽”，浏览器据此结合设备像素比算出该加载哪个 srcset 里的资源。
典型翻车点是 sizes 写死为 "100vw"——这等于说“永远占满视口”，但实际页面里图片常被容器限制宽度，比如卡片内最大宽 300px，这时候浏览器会误判，加载远超需要的大图。
立即学习“前端免费学习笔记（深入）”；
-
sizes值必须匹配 CSS 中图片的实际渲染宽度，例如sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 300px" -
srcset里每个图后面跟的w单位是“自然宽度”，不是文件大小，例如"large.jpg 1200w"表示这张图原始宽 1200px - 不要和
width/height属性混用，它们只影响布局盒，不影响sizes计算
<img src="fallback.jpg" srcset="small.jpg 480w, medium.jpg 768w, large.jpg 1200w" sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 300px" alt="描述文字" >
CSS background-image 响应式换图的局限与绕过方案
CSS 本身没有“按设备换背景图”的原生语法，@media 是唯一可靠方式，但要注意优先级和加载行为：即使媒体查询没命中，浏览器仍可能提前下载所有 background-image，造成带宽浪费；另外，CSS 无法像 <picture> 那样提供 webp fallback 或像素密度适配。
更隐蔽的问题是，当用 background-image 实现响应式 banner 时，如果只靠 background-size: cover，不同宽高比设备会裁剪不同区域，可能切掉重点内容——这不是技术问题，而是设计必须配合。
- 必须为每个断点单独写
background-image，不能用逗号拼多个 URL - 想实现像素密度适配，得手动写
@media (-webkit-min-device-pixel-ratio: 2)等私有前缀，不如 HTML 方案干净 - 如果背景图需要 SEO 或可访问性（比如 banner 文字依赖图片内容），坚决不用
background-image，改用<picture>+ 文字层叠
服务端 User-Agent 判断不是响应式图片的替代方案
有人想用 PHP 或 Nginx 根据 User-Agent 字符串返回不同图片，这看起来能精准识别设备，但实际不可靠：UA 可伪造、可被缓存污染、移动端浏览器 UA 字符串越来越趋同（比如 Chrome on Android 和桌面版几乎一样），而且 CDN 缓存会把一个 UA 的结果返回给所有人。
真正需要服务端介入的场景极少，比如内部系统已知只有 iPad 访问，且必须强制返回特定尺寸；或者要做 A/B 测试，按用户分群返回不同图。但这类需求和“响应式”无关，属于业务逻辑，不该混进前端适配流程。
记住：<picture> 和 srcset 是浏览器原生支持的、声明式的、可缓存的方案，只要用对，就足够覆盖 95% 的设备适配需求。复杂逻辑往服务端推，反而增加首屏延迟和运维负担。
