包裹+是唯一可靠方案，浏览器按type顺序匹配首个支持格式并停止，为强制兜底且必须含src与alt；WebP应置首（Chrome/Firefox/Edge超98%支持），AVIF次之，JPEG/PNG置于src中。
用 <picture></picture> 包裹 <source></source> + <img alt="HTML多规格图片怎么做降级适配" > 是唯一可靠路径
浏览器对图片格式的支持差异真实存在，不能靠 JS 检测后动态换 src——因为首次加载时已触发请求，降级逻辑根本来不及介入。必须用原生语义化结构让浏览器自己选。
关键点在于：<source></source> 的 type 属性决定优先级，<img alt="HTML多规格图片怎么做降级适配" > 是兜底；浏览器按顺序解析，遇到第一个能支持的 type 就停，不继续往下看。
-
<source type="image/webp" srcset="a.webp"></source>放最前，WebP 支持率在 Chrome/Firefox/Edge 里已超 98% -
<source type="image/avif" srcset="a.avif"></source>可加在 WebP 后面，但注意 Safari 16.4+ 才稳定支持 AVIF，旧版会跳过 -
<img src="a.jpg" alt="...">必须存在且带src，否则整个<picture></picture>渲染为空白（不是 fallback，是失效）
srcset 和 sizes 要配合物理尺寸写，别只写像素
单纯写 srcset="a-400w.jpg 400w, a-800w.jpg 800w" 在高 DPR 设备上会错选——浏览器按设备像素比放大计算，可能把 400w 当成 800 物理像素宽，导致小图被拉伸模糊。
正确做法是明确告诉浏览器“这张图在布局中占多宽”：
立即学习“前端免费学习笔记（深入）”；
- 如果容器固定为 300px 宽：
sizes="(max-width: 768px) 300px, 50vw" - 如果响应式全宽：
sizes="100vw"，但注意 iOS Safari 对100vw在横屏下有 bug，可补100vw, 100vh -
srcset中的宽度描述符（如400w）必须和sizes计算出的布局宽度匹配，否则浏览器无法准确换算 DPR
旧浏览器 fallback 不只是格式问题，还有特性缺失
IE11、部分安卓 4.x WebView 不仅不认 WebP，连 <picture></picture> 标签本身都当普通未知标签忽略，直接渲染内部 <img alt="HTML多规格图片怎么做降级适配" >——这看似是 fallback，实则埋了坑：
- 如果
<img alt="HTML多规格图片怎么做降级适配" >没写src（只靠 JS 注入），IE11 会显示破损图标 - 如果用了
loading="lazy"，IE11 会报错并中断后续脚本执行 - 某些老 Android 浏览器对
srcset解析异常，建议 fallback 图片保持和主图同尺寸，避免重排
验证方式：打开 DevTools → Network → Disable cache → 切到 IE11 User Agent，看是否发出 .jpg 请求且无控制台报错。
CDN 和缓存策略要区分格式，否则降级失效
很多团队把 WebP 和 JPEG 存同一路径，靠服务端根据 Accept 头返回不同内容——这在 <picture></picture> 场景下完全不可控：浏览器发多个 <source></source> 请求时，并不保证每个请求都带相同 Accept，CDN 可能缓存错版本。
安全做法是：
- WebP、JPEG、AVIF 分开存储，路径不同（如
/img/a.webp、/img/a.jpg） - CDN 缓存 key 明确包含文件扩展名，不依赖请求头
- 给所有图片加版本哈希（如
a-abc123.webp），避免格式切换时用户命中旧缓存
真正容易被忽略的是：当 WebP 文件体积更小，但 CDN 因缓存未刷新导致仍返回旧版大 JPEG，用户实际没享受到降级收益——得查 CDN 日志确认各格式请求占比，而不是只看 HTML 结构是否写了 <source></source>。
