如果你在iOS或macOS的Safari浏览器里打开一个网页，发现本该正常显示的图片变成了空白、红叉，或者一直在那转圈加载——而同一张图在Chrome或Firefox里却一点问题都没有——那问题往往出在WebP格式上。

说白了，就是服务器返回的是WebP格式的图片，但Safari压根不认这个格式，直接罢工了。

确认是否为WebP格式导致的问题

方法一：通过开发者工具检查

先别急着改代码，得确认问题到底出在哪。操作很简单：

• 在Safari里打开目标页面，按下 Option + Command + I 调出开发者工具。
• 切到“网络”标签页，刷新页面。
• 在过滤框里输入 .webp，或者随便点一个图片资源，看看右侧“标头”里的 Content-Type 字段。
• 如果显示的是 image/webp，而且状态码是200，那基本就找到元凶了。

方法二：直接打开图片检查

还有一个更直接的办法：在图片上右键（或者长按）选择“在新标签页中打开图像”，观察地址栏的URL后缀。如果以 .webp 结尾，而且新标签页一片空白或者提示“无法打开”，那基本可以锁定了。

小误区提醒

需要注意一个小误区：别光看网页源码里写的 就下结论。很多站点实际是通过服务端动态返回格式的，源码里的那个地址只是个占位符，真正返回什么得看网络请求的响应头。

前端适配：用 标签兜底

方法一，也是最直接的方法：给图片加一个双格式切换的兜底。适合静态页面或者图片数量不多的场景。

操作上很简单，把原来的 替换成下面这段代码：

浏览器会优先尝试加载 source 里声明的WebP资源；如果浏览器不支持（比如Safari），就自动回退到 img 标签里预备的PNG或JPG图片。

必须注意的细节：logo.png 这个文件必须真实存在，而且内容要和WebP版本完全一致，否则视觉上会出现错位。

后端适配：根据User-Agent动态转码

如果不想在前端挨个改图片标签，那就从后端下手。这里有两种常见方案。

方案一：Nginx配置自动识别

适用于自建服务器。在对应 server 块里加一段配置：

map $http_accept $webp_suffix {
  ~*webp ".webp";
  default "";
}

location ~* .(png|jpeg)$ {
  add_header Vary Accept;
  try_files $uri$webp_suffix $uri =404;
}

原理不复杂：当请求一张 icon.png 时，Nginx会检查请求头里有没有 Accept: image/webp。如果有，就尝试去找 icon.png.webp；找不到就返回原图。而Safari的请求头里压根不带这个标识，所以它永远走的是原图路径，完全不受影响。

方案二：阿里云OSS快速降级

如果你用的是阿里云OSS，连代码都不用改。在所有WebP图片的URL后面追加一个参数就行：x-oss-process=image/format,jpg。

举个例子：

• 原链接：https://bucket.oss-cn-hangzhou.aliyuncs.com/photo.webp
• 改为：https://bucket.oss-cn-hangzhou.aliyuncs.com/photo.webpx-oss-process=image/format,jpg

这样OSS会实时将WebP转码为标准JPG流，Safari可以直接解析。不需要预先生成副本，也不会增加存储成本。

CDN侧强制转码（Cloudflare等通用方案）

如果前端和后端都不想动，还可以在CDN层面解决问题。以Cloudflare为例：

登录Cloudflare控制台，进入对应域名，找到 Rules → Create Rule。Trigger 设置为 URL matches *.webp，Action 选择 Transform → Image Resizing，然后把 Format 设为 JPEG，Quality 设为 85。

这条规则生效后，所有匹配的WebP请求都会被CDN拦截，实时转为JPEG响应。即使用户看到的URL后缀仍然是 .webp，但实际收到的已经是JPG字节流了。

【关键前提】 确保你的Cloudflare套餐支持Image Resizing功能——Pro及以上套餐才有，免费版用不了这个功能。

《夸克》非常好用的免费AI浏览器

下载APP查看