<picture>是唯一可靠实现格式降级的原生方案，因<img src="x.webp">在Safari≤13.1、IE、旧Android WebView中静默留白；必须用<source type="image/webp">严格匹配MIME类型，并以静态路径JPEG/PNG的<img>兜底，且所有格式需尺寸与质量一致以防视觉跳变。
<picture> 是唯一能可靠实现格式降级的 HTML 原生方案，<img src="x.webp"> 在 Safari ≤13.1、IE、旧版 Android WebView 中会静默留白，不是“加载慢”，是根本没进解码流程。
为什么 <picture> 必须带 <source type="image/webp"> 和 <img> 兜底
浏览器对 type 属性做严格匹配：只有 type="image/webp"（不能是 "webp" 或 "image/WebP"）且服务器返回的 Content-Type: image/webp 一致时，才考虑加载该 <source>。不匹配就跳过，不报错也不警告。
-
<img>的src必须是静态可直访路径，例如/images/logo.jpg，不能带查询参数（如?format=webp或?x-oss-process=...），否则在不支持 WebP 的浏览器里可能返回 406 或损坏数据 -
<img>的alt不可省，否则无障碍和 SEO 都失效 - 所有格式图片的宽高、裁剪比例必须一致，否则切换时页面视觉跳变（CLIP）
<source> 顺序决定实际加载结果，不是“备选”而是“优先级队列”
浏览器从上到下逐条检查 <source>，满足两个条件即停止：① type 被当前浏览器支持；② 对应资源 HTTP 状态码为 2xx 且能解码。失败就继续往下看，直到找到可用项或退到 <img>。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 推荐顺序：
<source type="image/avif">→<source type="image/webp">→<img src="fallback.jpg"> - 不要把 JPEG 写成第三个
<source>：它只是格式 fallback，不是响应式 fallback，必须放在<img>的src里才起作用 - 若用
media属性（如media="(min-width: 768px)"），所有<source>都不匹配时才会触发<img>—— 这和格式 fallback 是两套逻辑，别混用
如何应对 <source> 加载失败却不降级到 <img>
这是最常被忽略的坑：<source> 加载失败（404、超时、格式损坏）时，浏览器不会自动跳到 <img>，它只在“无匹配 <source>”时才用 <img>。也就是说，media 条件满足但 srcset 地址无效，页面就留白。
立即学习“前端免费学习笔记（深入）”；
- 轻量方案：给
<img>加onerror内联处理，例如onerror="this.src='/images/fallback.jpg'; this.onerror=null;" - 健壮方案：用 JS 监听
error事件，但注意原生<source>不抛error，只能监听<img>自身；如需检测<source>失败，得用fetch()预检或 Service Worker 拦截 - 关键点：
this.onerror=null必须写，否则错误循环触发，反复尝试加载损坏地址
真正难的不是写对标签，而是让每种格式的图片在尺寸、压缩质量、元数据上保持一致——否则降级后用户看到的不是“更小的图”，而是“错位的图”或“突然变亮的图”。这需要构建时统一处理，而不是靠 HTML 临时协调。
