的顺序不能乱，因为浏览器从上到下匹配，遇到第一个type和media同时满足的即加载并停止；若jpeg写在avif/webp之前，支持新格式的浏览器也不会加载更优格式。
直接用 <picture></picture> 是最稳妥、原生、零 JS 依赖的兼容方案，但必须按 AVIF → WebP → JPEG/PNG 顺序写 <source></source>，且所有格式的 srcset 和尺寸需严格对齐，否则会白屏或加载错误。
为什么 <picture></picture> 的 <source></source> 顺序不能乱
浏览器从上到下逐个尝试 <source></source>，遇到第一个 type 匹配且媒体条件满足的就加载并停止。如果把 image/jpeg 放在前面，哪怕后面有 image/avif，AVIF-capable 浏览器也永远不会加载它。
常见错误现象：<source type="image/jpeg"></source> 写在最前 → 所有浏览器都只加载 JPEG，AVIF/WebP 彻底失效。
- AVIF 必须放第一个：
<source srcset="a.avif" type="image/avif"></source> - WebP 次之：
<source srcset="a.webp" type="image/webp"></source> - JPEG/PNG 回退必须放在
<img>的src属性里，不能写成第三个<source></source> - 所有
srcset值里的图片分辨率、质量档位、裁剪比例要一致，否则响应式切换时会出现拉伸或模糊
<img> 单标签能否支持 WebP/AVIF 自动降级
不能。单 <img src="x.jpg"> 只能加载一个 URL，浏览器不会主动替换格式。即使你用 CDN 动态转码（如 xxx.jpg?x-oss-process=image/format,avif），不支持 AVIF 的浏览器仍会收到 406 或损坏数据，导致图片不显示。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
使用场景：<img> 适合背景图（background-image: url(x.webp)）、图标、头像等无需艺术方向控制的静态资源 —— WebP 在 Chrome/Firefox/Safari 14+/Edge 全支持，足够稳；AVIF 则建议只用于首屏大图，且必须搭配 <picture></picture>。
- 纯 CSS 背景图无法做格式回退，
background-image不识别type或srcset - 服务端内容协商（如 Nginx 的
$http_acceptmap）可实现单 URL 多格式，但需后端配合，前端不可控 - JS 特征检测（
canvas.toDataURL('image/avif')）可行，但增加请求延迟和代码复杂度，不如原生<picture></picture>简洁
IE 和旧 Android WebView 怎么兜底
<picture></picture> 在 IE 中完全不被识别，会忽略整个标签，只渲染内部的 <img> —— 这反而是优势：只要 <img src="x.jpg"> 存在，IE 就能显示 JPEG。但旧版 Android WebView（
关键点：不要给 <img> 加 srcset 或 sizes，它只负责兜底，不是响应式主力。
- 确保
<img>的src是可直接访问的 JPEG 或 PNG，不能是带查询参数的动态地址（如?format=webp） - 避免在
<picture></picture>外再包一层<div> 做 fallback，IE 不解析 <code><picture></picture>时，DOM 结构可能错乱 - 若必须兼容 Android 4.4 WebView，加一行
<meta http-equiv="X-UA-Compatible" content="IE=edge">并测试渲染是否正常
最容易被忽略的是：所有 srcset 中的图片必须真实存在且 HTTP 状态为 200。浏览器不会因为某个 <source></source> 404 就跳到下一个 —— 它会卡住、报错，甚至阻塞后续资源加载。上线前务必用 curl 或 DevTools Network 面板验证每个 URL 是否可访问。
