浏览器加载jpeg而非webp，是因为与服务器返回的content-type响应头不完全匹配；必须按avif→webp→jpeg顺序排列，且为必需回退入口，尺寸须严格一致以防跳变。
为什么写了 <source type="image/webp"></source> 却还是加载 JPEG
不是浏览器“不支持 WebP”，而是链路中某处 type 和实际响应头不匹配。浏览器只认标准字符串 image/webp，且必须和服务器返回的 Content-Type 响应头完全一致。
-
type="webp"或type="image/webp "（末尾空格）→ 直接跳过该<source></source> - Nginx 未配置
types { image/webp webp; }→ 返回text/plain或空Content-Type - CDN 没透传
Accept: image/webp请求头 → 后端无法判断能力，统一返回 JPEG - DevTools Network 面板看到
blocked:mime-type或406 Not Acceptable→ 基本可定位到服务端配置问题
<picture></picture> 的 <source></source> 顺序为什么不能乱
浏览器从上到下逐个尝试 <source></source>，遇到第一个 type 可解码且 media 条件满足的就加载并停止——这不是建议，是执行逻辑本身。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
image/avif必须放最前：<source srcset="a.avif" type="image/avif"></source> -
image/webp居中：<source srcset="a.webp" type="image/webp"></source> - JPEG/PNG 回退必须放在
<img>的src属性里，不能写成第三个<source></source> - 把
<source type="image/jpeg"></source>放在 WebP 前面 → 即使设备支持 WebP，也永远加载不到
<img> 不是“备用 source”，而是所有老浏览器唯一入口
<picture></picture> 本身不加载图片，真正触发加载的是内部匹配成功的 <source></source> 或必需的 <img>。没有 <img>，就不会渲染任何内容，也不会发请求。
- IE 和旧 Android WebView 完全不识别
<picture></picture>，会忽略整个标签，只渲染内部的<img>—— 这反而是优势 -
<img src>不能是带查询参数的动态地址（如?format=webp），也不能是 404 路径；否则整个<picture></picture>会退化为仅显示alt文本 -
<img>的src必须指向真实可用的 JPEG 或 PNG，且尺寸、构图需与其他格式一致，否则切换时会出现拉伸或视觉跳变 - 首屏关键图应在
<img>上加fetchpriority="high"，提升 LCP；加在<source></source>上无效
WebP 在 CSS 里没法做格式回退
background-image: url(x.webp) 这种写法没有任何降级能力。CSS 不识别 type 或 srcset，也不触发浏览器的格式协商机制。
- 想让背景图也支持 WebP → JPEG 回退，只能靠服务端内容协商（需后端配合
Accept头判断 + 动态返回），前端无解 - 图标、头像等静态资源可用
<img>单标签 + CDN 动态转码（如阿里云 OSS 的?x-oss-process=image/format,webp） - 纯
<img>标签无法自动降级：直接写<img src="xxx.webp">会导致 Safari 13.1 之前、旧版 Edge 等浏览器显示空白
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
