同一张图片，同一个地址，在同事的新电脑上显示正常，到了另一台旧电脑的浏览器里却变成一块裂图。这种表现不一致的情况，最容易被误判成图片文件损坏，于是反复重传，时间花了不少，问题却还在。更稳妥的排查思路是先分清三种可能：文件本身有问题、传输环节被改动、浏览器不支持。三层分开看，排查才有方向。
第一层：核对文件本身
先确认图片文件是否完整。WebP有三种常见编码方式：有损压缩、无损压缩和动图。旧版浏览器对无损WebP和动图WebP的支持往往更晚，如果图片恰好是这两种，兼容问题就会先暴露出来。同时要确认文件大小和尺寸是否正常，上传过程中网络中断可能产生不完整的文件，这种文件在新浏览器里也许能勉强渲染，在旧环境里就直接裂开。可以下载原文件，用本地看图工具打开，确认能完整显示，再比对文件大小与源文件是否一致。
第二层：核对服务端响应
打开浏览器开发者工具，看图片请求返回的Content-Type是不是image/webp。有些服务器或CDN配置会把未知类型统一返回成application/octet-stream，浏览器就不敢当图片渲染。还要确认图片有没有经过二次压缩或自动转码，部分图片处理服务会根据请求头里的Accept字段决定输出格式，如果判断逻辑有误，可能给旧浏览器返回了它不认识的格式。检查响应头和实际返回的字节内容是否一致，是这一层的关键动作。
第三层：核对浏览器兼容
WebP的支持情况要看具体版本，不能只看浏览器名称。较老的IE系列完全不支持，部分旧版Safari和安卓系统WebView也需要较新版本才支持。如果图片是在小程序或App内嵌页面里显示，还要看宿主环境的WebView版本，它常常比系统自带浏览器更旧。可以整理一份检查清单：确认用户使用的浏览器名称与版本、确认是否内嵌环境、确认该版本是否在支持范围内，三项对齐后再判断是不是兼容问题。
第四层：核对降级方案
与其赌用户都换了新浏览器，不如让页面具备兜底能力。常见思路是用格式探测加备用图源：页面加载时先判断当前环境是否支持WebP，支持就加载WebP，不支持就切换到JPG或PNG备用图。也可以由服务端根据请求头返回对应格式。重点是不要只依赖单一格式，尤其是面向用户群体设备差异较大的站点，备用图源应当在上线前就准备好并测试过。
可执行的排查顺序
把上面的内容整理成可执行的排查顺序：先下载原文件确认完整，再看响应头类型是否正确，然后确认用户浏览器与WebView版本，最后检查降级方案是否生效。常见错误包括只在新浏览器里测试就上线、把图片类型配置写错、备用图源路径失效、以及忽略内嵌环境的版本差异。这些问题单看都不复杂，叠在一起就容易变成反复出现的裂图投诉。
网站维护里，兼容性检查最好前置到上传和发布环节，而不是等用户反馈再回头找原因。it数运在网站维护中强调把技术问题说明白，把交付过程做清楚，图片格式支持这类细节正属于需要提前说明和验证的部分。具体支持情况以各浏览器官方文档为准，遇到复杂环境时，建议结合实际测试结果判断。
