srcset本身不提供格式降级能力，仅做分辨率/密度选择；真正兜底必须依赖src属性，且src必须指向真实可加载的兼容图（如.jpg），否则浏览器在srcset失败时将显示空白。
srcset 本身不提供格式降级能力，它只做分辨率/密度选择；所谓“兜底”必须靠 src 属性完成，且该值必须是真实可加载的兼容图（如 .jpg 或 .png）。
为什么 srcset 单独写无法 fallback 到 JPG
浏览器看到 srcset="a.webp 1x, a.jpg 1x"，会照单全收——但它不会因为不支持 image/webp 就跳过 a.webp 去加载 a.jpg。它只会尝试加载第一个匹配描述符的 URL（即 a.webp），失败后直接 blank，根本不会看第二个。
这是常见误解的根源：把 srcset 当成多选一的 fallback 列表，其实它是“候选池”，浏览器只挑一个加载，不支持就失败。
-
srcset的作用域仅限于“同一格式下的尺寸/密度适配”，不感知 MIME 类型 - 所有现代浏览器（含 Safari 14.1+）都按规范执行此逻辑，不是 bug，是设计如此
- 如果你在 Network 面板看到
a.webp返回 404 或blocked:mime-type，那张图就彻底失效，不会自动切到a.jpg
srcset + src 才构成真正有效的降级链
正确姿势是：用 srcset 提供高优资源（WebP/AVIF + 多尺寸），用 src 提供最终、必加载的兼容图。浏览器在 srcset 加载失败时，会静默回退到 src ——但前提是 src 指向的是一个真实存在、服务器返回 200 OK 且 Content-Type 正确的图。
立即学习“前端免费学习笔记（深入）”；
-
src必须存在，不能为空、不能是占位符 URL（如data:image/gif;base64,...）、不能带无效查询参数（如?format=webp） -
src应优先选体积小、解码快的.jpg（非.png，除非需要透明） - 若你用 CDN 动态转码（如
photo.jpg?x-oss-process=image/format,avif），src仍需指向原始 JPG 地址，否则旧浏览器拿到的是 AVIF 数据却无 MIME 支持，显示空白
什么时候 srcset 会静默失效并 fallback 到 src
这不是“主动降级”，而是浏览器在 srcset 决策链中找不到可用项后的兜底行为。触发条件包括：
- 所有
srcset中的 URL 返回非200（如 404、403、CORS 拒绝） - 设备 DPR 为 1.5，但你只写了
1x, 2x，没覆盖中间值，浏览器可能选不到匹配项 -
sizes写错（如sizes="100vw"但实际容器被 CSS 限制为max-width: 300px），导致浏览器计算出的目标宽度超出所有w描述符范围 - 用了
w描述符却漏写sizes，浏览器默认按100vw计算，结果选了远超需要的大图，加载超时或失败
这些情况都不会报错，Network 面板里可能只看到一次请求（src 的那个），srcset 条目被完全忽略。
IE 和老 Android WebView 的兼容底线在哪
IE 完全不解析 srcset，只读 src；老版 Android WebView（如 4.4）对 srcset 支持极差，常出现白屏。这意味着：
-
src不仅是 fallback，更是“生存线”——它必须能在最差环境下独立工作 - 不要把
src设为photo.avif或photo.webp，哪怕你只面向新浏览器开发，CDN 或缓存层异常也可能让旧 UA 拿到错误格式 - 如果项目必须兼容 IE，别依赖
srcset做核心图片展示，改用picture+ polyfill（如picturefill），或服务端 UA 判断直出img标签
真正容易被忽略的点是：src 的可靠性不取决于你写了什么，而取决于它是否在任意网络、任意 UA、任意 CDN 状态下都能稳定返回一张可用图——这要求你把它当成一个独立部署的静态资源来管理，而不是“顺便写的备用地址”。
