必须用<picture>仅当需艺术指导或格式降级：如按屏幕尺寸切换构图、优先AVIF并回退WebP/JPEG、或media与type双条件组合匹配；其余情况一律用<img> srcset/sizes实现响应式。
绝大多数情况下，你应该用 <img>，而不是 <picture>；只有当 <img> 无法满足「艺术指导」或「格式降级」需求时，才必须上 <picture>。
什么时候必须用 <picture>？
不是“更高级就该换”，而是 <picture> 解决的是 <img> 根本做不到的事：
- 需要为手机裁一张竖版特写、为桌面展示宽幅全景图——
<source media="(min-width: 768px)">这类条件切换，<img>完全不支持 - 想优先用
image/avif，但必须给不支持的浏览器回退到image/webp或image/jpeg——<source type="image/avif">是<picture>独有的能力 - 要同时按屏幕尺寸 + 图片格式组合匹配（比如“大屏且支持 AVIF”才加载
large.avif）——<source>支持media和type双条件叠加，<img>的srcset只能处理分辨率维度
<img> 的响应式能力被严重低估了
很多人以为 <img> 只能塞一个 src，其实它原生支持完整的响应式图片逻辑：
-
srcset告诉浏览器“我有这些分辨率版本”，比如small.jpg 400w, medium.jpg 800w, large.jpg 1200w -
sizes告诉浏览器“在不同视口下，这张图大概占多宽”，比如(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw - 浏览器自动算出当前设备最合适的宽度，再从
srcset中选最接近的资源——整个过程无需 JS，无兼容性风险 - 写法简洁：
<img src="medium.jpg" srcset="..." sizes="..." alt="...">就够了，不需要包裹<picture>
容易踩的坑：误用 <picture> 反而降低性能
常见错误操作会拖慢加载、增加维护成本：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 只为了“多个尺寸”就套
<picture>，比如里面只写一个<source srcset="a.jpg 400w, b.jpg 800w">——这纯属冗余，<img>原生就能干，还少一层 DOM -
<picture>里漏掉<img>标签，导致所有浏览器都 fallback 失败，图片直接不显示 - 把
<source>顺序写反，比如把宽屏media="(min-width: 1200px)"放在前面，窄屏规则放在后面——浏览器按顺序匹配，第一个满足的就停，结果小屏也加载了大图 - 在 React/Vue 组件里无差别封装
<picture>，但实际业务图几乎全是单构图+JPEG/JPG，白加一层抽象
<picture> 的 <img> 不是摆设
<picture> 最后那个 <img> 不是可选项，是强制兜底项：
- 所有
<source>都不匹配时，浏览器必须加载它的src - 它的
alt属性是整组图片的无障碍描述，不能空着或乱写 - 即使你写了
<source type="image/avif">，也要保证<img src="fallback.jpg">是真实存在的、可访问的资源 - 别试图在
<img>里再写srcset——它只负责兜底，不参与响应式选择
真正复杂的点在于判断「要不要切构图」和「要不要保格式」——这两个问题一旦存在，<picture> 就不可替代；但只要图片内容一致、仅需适配尺寸，<img> 就是最简、最稳、最兼容的选择。
