<picture>是唯一零JS、不发额外请求、SEO友好、原生支持的响应式图片方案；浏览器自上而下匹配首个满足type支持与media条件的<source>即加载并停止，故AVIF必须置顶、WebP居中、JPEG/PNG回退须置于<img src>中。
直接用 <picture>，别绕弯子——这是唯一零 JS、不发额外请求、SEO 友好、原生支持的方案。
为什么 <source> 顺序不能乱
浏览器从上到下逐个尝试 <source>，遇到第一个 type 支持且媒体条件满足的就加载并停止。如果把 image/jpeg 写在最前，哪怕后面有 image/avif，AVIF-capable 浏览器也永远不会加载它。
-
image/avif必须放第一个：<source srcset="a.avif" type="image/avif"> -
image/webp次之：<source srcset="a.webp" type="image/webp"> - JPEG/PNG 回退必须放在
<img>的src属性里，不能写成第三个<source> - 所有
srcset值里的图片分辨率、质量档位、裁剪比例要一致，否则响应式切换时会出现拉伸或模糊
<img> 单标签能否支持 WebP/AVIF 自动降级
不能。单 <img src="x.jpg"> 只能加载一个 URL，浏览器不会主动替换格式。即使你用 CDN 动态转码（如 xxx.jpg?x-oss-process=image/format,avif），不支持 AVIF 的浏览器仍会收到 406 或损坏数据，导致图片不显示。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
<img>适合背景图（background-image: url(x.webp)）、图标、头像等无需艺术方向控制的静态资源 - 纯 CSS 背景图无法做格式回退，
background-image不识别type或srcset - IE 和旧 Android WebView 怎么兜底：
<picture>在 IE 中完全不被识别，会忽略整个标签，只渲染内部的<img>——这反而是优势：只要<img src="x.jpg">存在，IE 就能显示 JPEG - 但旧版 Android WebView（
<picture>出错，导致空白；所以务必确保<img>的src是可直接访问的 JPEG 或 PNG，不能是带查询参数的动态地址（如?format=webp）
如何让 <picture> 真正 fallback 到默认图
<picture> 的设计逻辑是：浏览器按 <source> 顺序匹配，仅当至少一个成功加载时才渲染；若所有 <source> 均因 404、跨域或网络中断而失败，浏览器仍会尝试渲染 <img> ——但若它的 src 也失效，最终只呈现 alt 文本，而非预期的备用图。
立即学习“前端免费学习笔记（深入）”；
- ✅ 最简洁可靠的方式：直接将
<img>的src指向一个高可用默认图（如 CDN 托管的占位图），而非无效路径 - ⚠️ 注意：
<img>不是“备用 source”，而是<picture>的必需子元素和最终渲染载体；它的src必须可加载 - ✅ 若需动态切换（如主题换肤），可用内联
onerror：<img src="broken.jpg" onerror="this.src='/placeholder.jpg'">；优势是无需额外 JS、兼容 IE9+；局限是不适用于复杂srcset/sizes场景，且多次触发可能重复请求 - ✅ 对复杂应用，建议用事件委托统一监听：
document.addEventListener('error', e => { if (e.target.tagName === 'IMG' && e.target.closest('picture')) e.target.src = '/fallback.jpg'; })
最容易被忽略的是：所有格式的图片必须尺寸一致、构图一致，否则视觉跳变；fetchpriority="high" 要加在 <img> 上，不是 <source>——否则无效。
