avif 必须置于 第一位且 type="image/avif" 写全， 的 src 需为无参 jpeg/png 作为降级底线，所有格式图片须尺寸、构图、色彩空间一致。
AVIF 必须放在 <source></source> 第一位，否则现代浏览器根本不会加载它；<img> 的 src 必须是 JPEG 或 PNG，且不能带查询参数。
AVIF 放第一个 <source></source> 是硬性顺序要求
浏览器从上到下扫描 <source></source>，遇到第一个 type 声明支持 + 实际能解码的就停止。AVIF 虽然压缩率高、质量好，但 Safari 16.4 之前、旧版 Android WebView、部分企业内网环境仍不支持——这恰恰说明它不能靠后：一旦被 JPEG 或 WebP 挡在后面，连尝试机会都没有。
-
type="image/avif"必须写全，不能写成type="avif"或type="image/avif+webp" - 服务器返回的响应头
Content-Type必须严格匹配，比如返回image/avif，否则 Safari 会静默跳过 - 如果用 CDN（如 Cloudflare、阿里云 OSS），需确认其支持透传
Accept请求头，并根据Accept: image/avif,image/webp动态返回对应格式
<img> 的 src 不是可选项，而是降级底线
<picture></picture> 本身不渲染、不请求，真正触发加载的是最终匹配的 <source></source> 或内部 <img>。漏掉 <img>，或它的 src 指向一个 AVIF 地址，IE、旧 WebView 就会白屏——不是报错，是直接不显示。
-
<img src="logo.jpg" alt="Logo">中的logo.jpg必须是真实可访问的 JPEG/PNG 文件，不能是logo.jpg?format=avif这类动态地址 - 不要给
<img>加srcset或sizes：它是兜底角色，不是响应式主力 -
alt属性不可省，否则无障碍和 SEO 全失效
所有格式图片必须尺寸一致、构图一致
AVIF/WebP/JPEG 三者只是编码不同，不是内容不同。如果 logo.avif 是裁剪过的竖版，而 logo.jpg 是横版原图，用户切到旧浏览器时会看到明显视觉跳变——这不是格式问题，是设计断层。
- 生成时统一用相同宽高、相同裁剪比例、相同质量档位（如 85%）
- 避免用工具“自动转 WebP”却不校验输出尺寸，很多 CLI 工具默认保留元数据或改变 canvas 大小
- 首屏大图建议用 AVIF，图标、头像等小资源优先 WebP 即可，AVIF 编码耗时高，对小图收益不明显
IE 和旧 Android WebView 的兜底行为很特殊
IE 完全不认识 <picture></picture>，会忽略整个标签，只渲染内部 <img> ——这反而是优势。但 Android 4.4 WebView（基于旧版 Chromium）会解析 <picture></picture> 却无法正确处理 <source></source>，导致空白。
- 测试必须真机跑 Android 4.4/5.0，不能只靠 Chrome DevTools 的 UA 模拟
- 若业务仍需兼容这些环境，可在构建时加一层简单 JS 检测：
if (!HTMLPictureElement) { /* 插入 img 标签 */ }，但绝大多数场景直接依赖<img>兜底已足够 - 别在
<picture></picture>外再包一层<div> 做 fallback，这会破坏语义和可访问性<p>最容易被忽略的不是怎么写 <code><source></source>，而是所有格式图片是否真的“长得一样”。尺寸、裁剪、色彩空间稍有差异，用户在格式切换瞬间就会感知到跳动——这种体验断层，比多几 KB 流量更伤人。
