标签不提供自动适配，仅声明式资源选择；必须按匹配强度降序排列，须置于末尾并带src和alt；90%场景用srcset+sizes更安全；仅内容构图需变化时才适用；现代框架优先使用内置图片组件。
picture 标签不解决“自动适配”问题，它只提供声明式资源选择
很多人以为 <picture></picture> 会像 CSS 媒体查询一样“自动响应”，其实它只是把浏览器的资源选择权从单一 src 拆成一组明确规则。浏览器按顺序检查 <source></source>，遇到第一个匹配的就加载，剩下的全跳过——不预加载、不回退、不兜底。
常见错误现象：<source></source> 顺序错乱导致高分辨率设备加载了低清图；漏写 <img alt="HTML5Picture标签怎么用_HTML5响应式图片加载实现教程【介绍】" > 的 src 或 srcset，结果所有浏览器都 fallback 到空图或 404。
- 必须把最具体、限制最强的
<source></source>放前面（比如media="(min-width: 1200px) and (min-resolution: 2dppx)"） -
<img alt="HTML5Picture标签怎么用_HTML5响应式图片加载实现教程【介绍】" >必须放在<picture></picture>最后，且至少带src和alt——这是唯一强制渲染的节点 - 不要指望
<source></source>的type属性能“降级”：Chrome 支持image/avif就用它，不支持就直接跳过该<source></source>，不会尝试下一个
srcset + sizes 组合比单独用 picture 更常用也更安全
90% 的响应式图片需求其实不需要 <picture></picture>。比如同一张图在不同视口宽度下切换分辨率，用 <img srcset="..." sizes="..." alt="HTML5Picture标签怎么用_HTML5响应式图片加载实现教程【介绍】" > 就够了。它让浏览器自己算出最佳尺寸，兼容性更好（IE 不支持但有 polyfill），代码也更轻。
使用场景：博客文章配图、商品列表图、卡片头图——内容语义没变，只是清晰度或裁剪比例需调整。
立即学习“前端免费学习笔记（深入）”；
-
sizes值必须是媒体条件 + 宽度单位组合，例如"(max-width: 768px) 100vw, 50vw"，不能写成"100%"或漏掉单位 -
srcset中的每个项要用逗号分隔，且必须带w（如"small.jpg 400w"），不能混用x（如"big.jpg 2x"） - 如果服务器不支持根据
Accept头返回不同格式，type在srcset里无效——别白费劲
art-direction 场景才真正需要 picture 标签
当图片内容本身要随屏幕变化（比如桌面端展示全身照，移动端只展示脸部特写），这才是 <picture></picture> 的核心价值。这时候不是换分辨率，而是换构图，<source></source> 的 media 和 srcset 才有意义。
容易踩的坑：用 media="(min-width: 768px)" 却没给小屏提供等效信息量的图，导致移动端用户看到严重裁剪或空白区域。
- 每个
<source></source>的srcset应该对应一个独立裁剪/构图版本，不是简单缩放原图 - 确保所有
<source></source>和最终<img alt="HTML5Picture标签怎么用_HTML5响应式图片加载实现教程【介绍】" >的宽高比一致，否则 CSSobject-fit补救会失真 - 不要在
<source></source>里写src——它只认srcset，写了也忽略
现代项目优先考虑 image CDN 而非手写 picture
Next.js、Nuxt、Gatsby 这类框架默认用 next/image 或 <nuxtimg></nuxtimg>，背后自动处理 srcset、格式协商（AVIF/WebP）、懒加载和占位。手写 <picture></picture> 在这些环境里反而可能绕过优化逻辑，甚至触发重复请求。
性能影响：手动维护多套图片资源路径容易漏更新，CDN 则实时按请求参数生成最优图；兼容性上，CDN 可通过 UA 判断降级，而纯 HTML 的 <picture></picture> 依赖浏览器原生支持。
- 检查构建工具是否已注入图片优化插件（如
vite-plugin-imagemin），有就别自己折腾<picture></picture> - 如果必须手写，用
<picture></picture>前先确认目标浏览器支持率（CanIUse 显示<picture></picture>全局支持率达 98%，但 Android 4.4 WebView 是个雷区） - 所有
srcset中的路径必须可被静态服务器直接访问，别用 Webpack 的require()或 Vite 的new URL()动态路径——HTML 解析时根本看不到
