+ 是唯一可靠写法，因浏览器在html解析阶段依type属性协商格式，现代浏览器支持时加载webp并跳过兜底，旧版ie/safari则忽略直接使用降级。
直接用 <img src="x.webp"> 就是错的——不支持 WebP 的浏览器会显示空白，不是加载慢，是压根不渲染。
为什么 <picture></picture> + <source type="image/webp"></source> 是唯一可靠写法
浏览器在 HTML 解析阶段就根据 type 属性做格式协商，不看文件后缀、不嗅探二进制内容、也不等 JS 执行。IE11、Safari ≤13.1 等旧环境会直接忽略 <source></source>，退到 <img> 兜底；而 Chrome/Firefox/Edge 等现代浏览器看到 type="image/webp" 且支持时，会加载 WebP 并跳过 <img>。
-
type="image/webp"是硬性判断依据，缺它等于没声明支持条件 - 多个
<source></source>时按顺序匹配，WebP 必须放在最前 -
srcset或sizes不影响兼容性判断，加了反而可能干扰语义 - Safari 14+（macOS 11.3 / iOS 14.5 起）才支持 WebP，更早版本静默跳过
<source></source>
document.createElement('canvas').toDataURL('image/webp') 检测的局限性
这个 JS 检测能告诉你当前浏览器是否具备 WebP 解码能力，但它无法替代 <picture></picture> 结构——因为检测发生在 DOM 渲染之后，图片早已开始加载或失败。
- 返回以
"data:image/webp"开头的字符串：支持（含透明通道） - 返回
"data:,"或false：不支持（如 IE11、Safari 13.0） - 旧版 Chrome（≤22）可能支持有损 WebP，但对带 alpha 的 WebP 返回
"data:,"，需额外检测toDataURL('image/webp', 0.8)是否含 alpha - 检测结果不能用于动态插入
<img src="x.webp">——此时 fallback 已失效
服务端自动转码（如 Cloudflare Polish）和客户端结构的关系
服务端优化只对发送了 Accept: image/webp 请求头的客户端生效；IE、旧 Safari 根本不发这个头，服务端连“转码”机会都没有。
- Nginx 配置 WebP rewrite 时，必须启用
ngx_http_image_filter_module或第三方 webp 模块，否则 404 比空白更糟 - CDN 自动转码（如 Cloudflare Polish）不会修改 HTML 结构，仍需客户端用
<picture></picture>声明意图 - 即使服务端返回 WebP，若 HTML 写成
<img src="x.jpg">，浏览器也不会去请求 WebP 版本 - 服务端和客户端是两层防线：服务端负责提供资源，客户端负责正确声明和降级
最容易被忽略的一点：WebP 支持 ≠ 自动降级。浏览器不会因为你上传了 .webp 文件就替你选格式，它只认 type 声明；而兜底图路径、alt 文本、宽高属性这些细节，一旦漏掉，就失去可访问性和 SEO 基础。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
