图片格式与响应头不一致，是许多网站图片显示异常的常见起点。尤其在WEBP逐渐普及之后，部分站点为兼容旧环境，会把WEBP文件的响应头标成image/jpeg，浏览器按JPEG解码，遇到WEBP数据自然无法还原。反过来，文件实际为JPEG却声明成image/webp，支持WEBP的浏览器也可能解析出错。排查时先取一张出问题的图片地址，查看响应头中的Content-Type，再核对文件头字节与声明是否匹配。两者不一致，优先修正服务端配置或上传转换逻辑，而不是先改前端代码。
页面是否提供多格式回退，同样值得细看。规范做法是用picture元素同时声明WEBP和JPEG来源，由浏览器按自身能力选择。常见错误是source顺序颠倒，把WEBP放在最后，或者只写了一个source，导致不支持WEBP的浏览器无路可退。核对时确认每个picture都有可用的JPEG或PNG兜底，source的type属性与实际格式对应，img标签保留默认地址。顺序和类型都正确，旧版Safari才有机会拿到它能解码的文件。
CDN缓存也可能把WEBP响应错误复用给不支持该格式的客户端。部分缓存策略只按URL缓存，不区分请求头中的Accept字段，第一个访客拿到WEBP响应后，后续所有客户端都收到同一份缓存。旧版Safari因此拿到无法解码的内容。核对时清理相关缓存，检查缓存键是否包含格式协商相关字段，或对图片响应设置Vary头。缓存层配置正确后，不同能力的浏览器才能各取所需。
用户上传端是否保留了原始格式与转换后格式的对应关系，是第四层要确认的事。有些系统上传后统一转成WEBP，却覆盖了原文件，回退时无图可用。维护中应确保原始JPEG或PNG保留在存储中，转换结果单独存放，数据库记录两者的映射关系。这样出现兼容问题时，可以快速切换回退地址，而不必要求用户重新上传。
日常可以按一份清单检查：响应头类型是否与文件一致，picture是否有有效兜底，source顺序与type是否正确，CDN缓存键是否区分格式，原始文件是否保留，转换记录是否可追溯。it数运在网站维护中处理此类问题，通常先复现失败环境，再按响应头、回退声明、缓存、上传源文件四层逐一验证，确认问题层级后再改动配置，避免多处同时调整导致新问题。
格式协商的本质是让每个浏览器拿到自己能解码的文件。响应头、回退声明、缓存策略、上传源文件四层依次排查，多数旧版Safari的图片显示问题都能定位到具体环节。具体情况应以相关官方规定和专业人士意见为准。
