客服转来一张截图，页面正文位置空出一块，文字被挤到下面，布局明显错位。用户说同一篇文章在别的设备上正常，只有这台苹果设备上图片不显示。后台查看，图片文件确实上传成功，链接也能打开。这类问题在网站维护中并不少见，尤其是WEBP格式普及之后，旧版Safari成了高频触发点。
先别急着改代码，第一步是分清这到底是格式支持问题，还是文件本身有问题。需要向反馈用户确认三项基础信息：浏览器名称与版本、系统版本、以及这张图片的来源和编码方式。旧版Safari对WEBP的支持是分阶段开放的，部分系统版本即使浏览器看起来较新，底层渲染引擎仍可能不支持该格式。如果用户系统版本偏低，而其他设备正常，基本可以锁定为格式支持差异。反过来，如果多台同版本设备都不显示，就要怀疑文件编码本身有问题，比如采用了有损以外的特殊编码模式，或者文件在传输过程中被截断。这三项信息不确认，后面的排查很容易做无用功。
第二层要看图片是怎么被引入页面的。img标签直接引用、CSS背景图、picture元素、懒加载脚本，这四种方式在兼容性上的表现并不相同。img标签遇到不支持的格式，通常表现为空白占位，布局仍按图片尺寸预留空间。CSS背景图不显示时，元素本身还在，只是背景透明，容易被误判为样式问题。picture元素如果写了source回退，理论上可以自动切换格式，但顺序写错或类型声明不匹配时，回退不会生效。懒加载脚本则可能把格式判断逻辑放在加载之后，导致不支持的格式被强行插入。维护时建议逐一确认图片的实际引入路径，而不是只看页面源码里有没有img。
第三层是服务端返回的Content-Type与文件扩展名是否一致。有些上传流程会把WEBP文件存成jpg扩展名，或者反过来，服务端按扩展名推断类型，返回了错误的MIME声明。浏览器拿到一个声明为image/jpeg、实际内容是WEBP的响应，解码阶段就可能直接失败，表现为空白而不是报错。核对方法是查看响应头中的Content-Type，与文件真实格式做比对。不一致时，优先修正服务端的类型推断逻辑，而不是在前端加补丁。
确认完这三层，处理路径大致有三条。格式回退适合图片数量不多、更新频率低的站点，上传时同时生成一张兼容格式的副本，前端按浏览器能力选择。条件加载适合已有较多历史图片的情况，通过特性检测决定是否请求回退资源，代价是增加一次判断和可能的额外请求。上传时转码则从源头解决，所有图片统一转为兼容性更好的格式，代价是失去WEBP的体积优势，需要结合页面性能预算权衡。三条路径没有绝对优劣，关键看站点图片存量和目标用户的设备分布。
上线前的抽查顺序可以固定下来：先查目标用户主力机型的系统版本分布，再抽查图片引入方式是否统一，最后核对服务端类型声明。多端抽查时，至少覆盖新旧两个大版本的苹果设备，以及主流安卓设备。具体采用哪种兼容策略，应以目标用户的实际设备分布和访问数据为准，必要时咨询专业技术人员评估。
