同一张图片在电脑浏览器里打开一切正常，转发到旧版Safari上却只剩一块空白区域，没有报错弹窗，也没有加载提示，看起来像是图片根本没被渲染。遇到这种情形，不少人的第一反应是文件损坏或上传中断，于是反复重传，结果依旧。实际上，这类问题多数与文件本身无关，而是浏览器的图片解码能力与文件实际格式对不上。网站维护中处理这类情况，需要按层次逐项核对，而不是凭感觉反复换图。
第一层，先确认文件的真实格式。扩展名可以手动修改，编码信息却不会随之改变。把图片下载到本地，用系统自带的文件信息查看，或者用十六进制工具读取文件头几个字节，WEBP文件开头通常有明确的标识字符。有些文件原本是其他格式，被手动改成.webp后缀，上传后在某些浏览器里能靠内容嗅探显示出来，在另一些浏览器里则直接放弃解码。维护时要把扩展名与实际编码一致作为基本要求，不一致的文件一律重新导出，不要带着隐患入库。
第二层，核对浏览器版本与解码范围。WEBP并非所有Safari版本都支持，较早的系统版本对静态WEBP的支持并不完整，动态WEBP的支持范围更窄。判断方法很简单，在目标设备上打开一个已知可用的WEBP测试页，如果同样空白，说明是浏览器能力问题，而不是你的文件问题。维护人员应记录网站需要覆盖的浏览器与系统版本范围，把超出支持范围的客户端列入需要回退的对象，而不是等用户投诉再处理。
第三层，核对页面是否准备了回退资源。对不支持WEBP的客户端，应提供JPG或PNG替代图。常见做法是在页面结构中使用图片元素的多源写法，让浏览器按自身支持情况选择，或者在脚本中先检测解码能力，再决定加载哪个地址。回退判断要写在资源加载之前，不能等图片加载失败再补救，因为解码失败往往不触发常规的错误回调。替代图应与原图尺寸比例一致，避免布局跳动。
第四层，核对服务端内容协商与缓存。如果同一图片地址会根据请求头返回不同格式，必须确认缓存键包含了格式差异，否则中间缓存可能把WEBP响应发给不支持它的客户端，或者把JPG响应长期留给支持WEBP的客户端。维护时要检查缓存策略是否与内容协商匹配，必要时为不同格式使用不同地址，减少缓存错乱的可能。
上线前的图片格式检查可以整理成一份清单：文件扩展名与实际编码是否一致；目标浏览器与系统版本是否在支持范围内；不支持时是否有可用的JPG或PNG替代资源；回退判断是否在加载前完成；同一地址是否存在多格式返回与缓存冲突。逐项打勾后再发布，比事后排查省力得多。
图片格式兼容不该靠临时救火。把它作为发布前的固定检查项，在素材入库阶段就识别格式、标注兼容范围、配好替代资源，后续维护会稳定很多。it数运在网站维护中通常把这类检查前置到素材入库环节，目的就是让问题在进入页面之前被发现，而不是等用户在旧设备上看到空白。
