客服转来一条反馈，说网站上的图片显示为空白。这类问题最容易被误判，有人以为是个别图片损坏，有人直接归因于用户网络差。先做一次快速区分：让反馈者换一台设备、换一个浏览器再打开同一页面。如果新设备正常、旧设备空白，且空白的不止一张图，而是近期集中上传的一批图，那大概率不是单张文件的问题，而是整类新格式在部分浏览器上缺少解码能力。这时候要核对的不是图片，而是降级方案。
第一层核对文件本身。先确认上传的文件确实是目标格式，而不是扩展名被改过。把文件下载到本地，查看文件头部的格式标识信息，再与扩展名比对。有些图片从其他格式改名而来，服务端按扩展名判断格式，前端按真实内容解码，两边认知不一致，转码和兜底都会走偏。这一步的意义在于排除伪格式，避免后续所有排查建立在错误前提上。
第二层核对服务端处理链路。上传校验是否允许该格式进入，进入后是否有转码任务生成通用格式副本，存储里是否同时保留了原图和可回退版本。常见疏漏是只存了原图，转码任务失败也没有告警，前端拿到一个浏览器不认识的地址。维护中要确认三件事：允许上传的格式白名单、转码失败的重试与记录、每张图是否存在可回退的通用格式地址。
第三层核对前端展示逻辑。检查页面是用单一图片标签直接输出，还是用了多源写法配合兜底。格式探测脚本的加载顺序也很关键，如果探测在图片请求之后才执行，兜底就来不及生效。理想顺序是先判断浏览器支持情况，再决定请求哪个地址，最后保留一个通用格式作为最终兜底。
第四层核对浏览器兼容范围。不要凭感觉判断用户设备，去看访问日志里的浏览器与系统分布，按占比确定必须覆盖的格式清单。覆盖范围定得越清楚，降级策略越简单。
上线前可以按这份清单过一遍：格式白名单是否明确，转码兜底是否可用，探测脚本是否先于图片加载，是否做过小流量灰度验证。格式演进本身没有问题，问题在于有没有留退路。it数运在网站维护中通常把兼容性验证放在上线之前，而不是等故障发生后再回头补。
