<picture>是唯一原生、零JS、SEO友好的WebP/AVIF降级方案，必须按<source type="image/avif">→<source type="image/webp">→<img src="fallback.jpg">顺序书写，type值须严格匹配标准MIME类型，且<img>的src必须为静态可直访的JPEG/PNG路径，任一错误均导致浏览器静默丢弃请求而留白。
直接用 <picture> + <source type="image/webp"> + <img src="fallback.jpg"> 就行，但顺序、type 值、兜底路径三处写错一个，图片就空白——不是“不生效”，是浏览器根本不会请求。
为什么 <img src="x.webp"> 不能当降级方案
旧版 Safari（≤13.1）、IE、Android WebView 4.4 之前版本压根不认识 image/webp MIME 类型。它们看到 src="x.webp" 不报错、不警告，直接静默丢弃请求，页面留白。这不是加载慢，是根本没发请求。
-
<picture>是唯一原生支持格式协商的 HTML 元素，无需 JS，SEO 友好，且不触发额外请求 -
<source>的type属性是开关：只有值完全匹配标准 MIME 类型，浏览器才考虑加载对应资源 - 写成
type="webp"或type="image/jpg"→ Safari 直接跳过，Chrome 可能侥幸加载但不可靠
<source> 的顺序和 type 值必须严格按支持强度排列
浏览器从上到下逐条检查 <source>，遇到第一个 type 被支持 *且* 对应资源可解码（文件存在、格式合法、网络可达）就停止，不再往下看。
- 推荐顺序：
<source srcset="a.avif" type="image/avif">→<source srcset="a.webp" type="image/webp">→<img src="a.jpg" alt="..."> - AVIF 放最前：Chrome 120+ / Firefox 120+ 已稳定支持；Safari 16.4+ 开始支持，但 iOS 16.4 以下仍不行，需靠后续 fallback
- WebP 放中间：覆盖 iOS 14+、Android 4.0+、所有现代桌面浏览器
- JPEG/PNG 必须落在
<img>的src里，不能写成第三个<source>——否则 IE 和旧 WebView 会忽略整个<picture>，导致空白
<img> 的 src 是强制兜底，不是“可有可无”
<picture> 自身不渲染、不请求，真正触发加载的是匹配成功的 <source> 或最终的 <img>。漏掉 <img>，或它的 src 指向无效地址，整个结构就失效。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
src必须是静态、可直访的 JPEG/PNG 地址：在浏览器地址栏粘贴该 URL 应能直接显示图片 - 禁止带查询参数：
src="logo.jpg?format=webp"或src="logo.jpg?x-oss-process=image/format,avif"→ 旧浏览器可能返回 406 或损坏数据 -
alt属性不可省：缺失会导致无障碍失败、SEO 折损，且部分屏幕阅读器会跳过无alt的<img> - 所有格式图片的宽高、裁剪比例、构图必须一致，否则切换时视觉跳变（比如 AVIF 是居中裁切，JPG 是顶部对齐）
服务器 Content-Type 必须和 type 值完全一致
浏览器只看两个东西：HTML 中写的 type 值，和服务器响应头里的 Content-Type。二者差一个字符，Safari 就静默跳过，不加载也不报错。
- WebP 文件必须返回
Content-Type: image/webp - AVIF 文件必须返回
Content-Type: image/avif - JPEG 必须是
image/jpeg，不是image/jpg或image/jpe - CDN 或 Nginx 若未透传
Accept请求头（如Accept: image/avif,image/webp,*/*），后端无法按需返回对应格式，容易触发 406
最容易被忽略的其实是尺寸一致性：AVIF/WebP/JPEG 三张图若宽高比或裁剪逻辑不同，用户在 Safari 切换到 Chrome 时会看到画面突然偏移或拉伸——这和代码无关，是素材管理问题。
