不是万能的，它仅在需艺术指导或格式降级时才必要；日常宽度适配用srcset+sizes更轻量可靠，因依赖精准的media匹配、正确顺序及回退，否则易失效。
直接说结论：用 <picture></picture> + <source></source> 是解决“美术方向裁剪”和“格式降级”的最优解，但多数场景下 srcset + sizes 更轻量、更可靠；光靠 CSS 缩放或 background-image 做不了真响应式。
为什么 <picture></picture> 不是万能的？
很多人一上来就套 <picture></picture>，结果发现图片没换、加载变慢、甚至 fallback 失效。根本原因是它只在特定条件下生效：
-
<source></source>的media属性必须匹配真实布局断点（比如(max-width: 768px)），不能照搬设计稿的“移动端”说法 - 所有
<source></source>必须写在<img>标签之前，顺序错一个，整个<source></source>就被忽略 -
type="image/webp"只控制 MIME 类型识别，不保证浏览器一定加载——得看是否支持 WebP，且该<source></source>被选中 - 如果所有
<source></source>都不匹配，浏览器才回退到<img src>；但如果你忘了写<img>或漏了alt，可访问性和 SEO 就全崩了
srcset + sizes 怎么配才不白写？
只写 srcset 不写 sizes，等于告诉浏览器：“你猜这张图在页面里占多宽”。浏览器默认按 100vw 算，结果小屏也下大图。
-
sizes是字符串，不是 CSS：写成sizes="(max-width: 768px) 100vw, 50vw"才对；calc()、CSS 变量、百分比单位都无效 -
srcset里标w（如hero-480w.jpg 480w）时，sizes必须提供对应上下文宽度；标x（如hero@2x.jpg 2x）时，sizes可省略，但仅适用于 DPR 适配 - 生成图片宽度建议按 1.5× 步进：320w、480w、768w、1200w、1920w，覆盖主流设备逻辑像素宽度，别硬凑整千整百
- 测试时打开 Chrome DevTools → Network → Disable cache + Throttle 到 “Slow 3G”，再切设备尺寸，看实际加载哪张图
哪些情况必须用 <picture></picture>？
只有两类问题绕不开 <picture></picture>：
-
艺术方向裁剪（art direction）：比如移动端用竖构图人脸特写，桌面端用横构图全景——单靠
srcset无法切换图像内容，只能换分辨率 - 格式优先级控制：想让支持 WebP/AVIF 的浏览器优先加载，不支持的自动降级到 JPEG/PNG，且不希望 JS 检测或服务端判断
注意：<picture></picture> 本身不压缩图片、不减少请求数、也不提升首屏速度；它只是把选择权交给浏览器。真正提速还得靠图片压缩、CDN 分发、懒加载配合。
CSS 层面最容易被忽略的三件事
就算 HTML 写对了，图片照样会拉胯：
-
max-width: 100%和height: auto必须同时加在<img>上；只加 width 或只加 height 会导致变形或溢出 -
object-fit只对<img>生效，对background-image无效；IE 完全不支持，需要 fallback 方案（比如用<div> + <code>background-image+ 媒体查询） - 父容器没设宽高约束时，
max-width: 100%会失效——比如 Flex 容器里子项没设flex-shrink: 1，或 Grid 轨道用了fr却没设min-width: 0
最常踩的坑是：以为写了 <picture></picture> 就万事大吉，结果图片体积没压、CDN 没配、父容器锁死宽度、DevTools 里根本没验证实际加载的是哪张资源。
