不能用css做webp降级，因ie、safari≤15.3等浏览器不识别image/webp格式且无fallback机制；@supports无法检测格式解码能力，image-set()兼容性差且不触发内容协商；唯一可靠方案是html的元素。
不能用 CSS 做 WebP 降级——这是根本性限制，不是写法问题。 background-image: url(x.webp) 这种写法在 IE、Safari ≤15.3、Android 4.4 WebView 等环境里只会加载失败或留白，浏览器不识别格式协商，也不触发 fallback 机制。
为什么 @supports (background-image: image-set(...)) 行不通
@supports 检测的是属性值语法是否被支持，不是图片格式是否可解码。image-set() 在 Safari 15.4+ 才开始部分支持，且必须配合 -webkit- 前缀；Chrome 虽支持但对 WebP 的 type 协商仍依赖服务器 Content-Type，CSS 层面无法干预。更关键的是：@supports 规则本身在 IE11 及更早版本中被整块忽略，连 fallback 都没机会执行。
- 写
@supports (background-image: image-set(url(a.webp) type("image/webp")))→ Safari 15.3 及以下直接跳过整条规则，无 fallback - 即使检测通过，
image-set()也不等价于<picture></picture>：它不发送 Accept: image/webp 请求头，后端无法按需返回 WebP - 所有主流浏览器都不支持在
image-set()中混用不同 MIME 类型（如 webp + jpeg），会静默失败
真正可行的降级路径只有两种
一种是服务端内容协商（需后端配合 Accept 头判断），另一种是前端用 <picture></picture> ——后者是唯一零 JS、SEO 友好、不发多余请求的方案。CSS 本身没有“图片格式降级”能力，强行塞进 CSS 会导致：
- IE 加载空白（
background-image解析失败即丢弃整条声明） - Safari 9–15.3 渲染为默认背景色或继承色（无 fallback 声明时）
- Android 4.4 WebView 对 base64 WebP 数据 URI 支持极差，常解码失败
若坚持用 CSS，唯一勉强可用的“伪降级”是靠 Modernizr 注入类名 + 手动写两套 background-image，但要求：
-
上必须有no-webp类（Modernizr 默认加） - fallback 必须用
rgb()或#rrggbb，不能用任何新颜色函数 - WebP 版本需提前转成 data URI（否则跨域或路径问题导致加载失败）
如果你必须用 background-image，至少避开这些坑
别指望浏览器自动 fallback，你得自己控制加载逻辑。常见错误包括：
- 把
url(a.webp)和url(a.jpg)写在同一声明里，如background-image: url(a.webp), url(a.jpg)→ 旧浏览器只尝试第一个，失败即停，不会试第二个 - 用
@supports (color: oklch(0% 0 0))包裹 WebP 背景 → 语义完全错位，oklch 和图片格式无关 - 在 CSS 中写
background-image: url(a.jpg?format=webp)→ 服务端未配置时，旧浏览器拿到 404，现代浏览器也拿不到 WebP
真要保底，只能用内联 style + JS 动态设置：element.style.backgroundImage = 'url(' + (supportsWebp ? 'a.webp' : 'a.jpg') + ')'，但这就脱离了“纯 CSS 优雅降级”的前提。
最易被忽略的一点：所有降级方案都依赖服务器正确返回 Content-Type: image/webp。Nginx 缺少 types { image/webp webp; }，或 CDN 未透传 Accept: image/webp，<picture></picture> 也会退化为 JPEG——这时候查 DevTools Network 面板里的 MIME 类型比调 CSS 更管用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
