后台显示上传成功，图片在自己的新电脑上打开也正常，可换到另一台旧版本浏览器却只剩一片空白。类似情况在网站维护中并不罕见。AVIF压缩率高、体积小，近来越来越多站点开始采用，但旧版本浏览器的支持并不同步。遇到空白图，先别急着重传，也不要立刻认定文件损坏，更常见的原因是回退链路没有做完整。排查顺序可以从文件本身开始，一层层往交付端核对。
第一层，确认AVIF文件本身能否被解码。把原文件下载到本地，用支持AVIF的独立图片查看器打开，观察画面是否完整、有无灰块或截断。如果独立查看器也打不开，问题出在文件生成或上传环节，比如导出中断、尺寸超限、色彩信息异常。只有确认文件本身可解码，后面的回退排查才有意义。反过来，如果文件正常而网页空白，说明问题在交付路径上。
第二层，核对服务端的内容协商。部分站点为了统一，会把图片地址一律输出AVIF，忽略了请求头里的格式偏好。正确的做法是读取浏览器发送的Accept信息，支持AVIF的返回AVIF，不支持的返回JPEG或WebP。检查时可以借助浏览器开发者工具查看实际响应类型，确认返回格式与请求预期一致。如果所有请求都拿到同一种格式，回退就无从谈起。
第三层，核对前端picture元素与source的书写顺序。回退链依赖浏览器自上而下匹配，顺序写反会把不支持的格式优先命中。常见写法是先放AVIF的source，再放WebP，最后用img标签兜底JPEG。需要留意的是，img的src不能空缺，type属性要与实际格式对应，遗漏type可能导致浏览器误判。顺序错误往往表现为新浏览器正常、旧浏览器空白，很容易被误认为兼容性无解。
第四层，核对CDN缓存。内容协商生效后，如果缓存层没有区分格式，就可能把一份AVIF缓存给所有请求，导致旧浏览器拿到无法解码的内容。检查缓存键是否包含格式维度，必要时对图片响应设置合理的Vary头，并在调整后清理相关缓存。缓存问题具有滞后性，修改配置后要观察一段时间再下结论。
上线前可以按一份简单清单自查：原文件可解码、服务端按请求返回格式、picture回退链顺序正确、缓存区分格式、关键页面在旧版本浏览器实测。灰度验证时先放少量流量，观察空白图报错是否下降，再逐步扩大范围。it数运在网站维护中处理这类问题时，也是按文件、服务端、前端、缓存四层依次核对，避免在错误环节反复修改。
最后提醒一句，浏览器对AVIF的支持情况会随版本变化，具体以目标用户实际使用的浏览器为准。回退方案不是可选项，而是图片上线流程的一部分。把这条链路检查清楚，空白图问题大多能定位到具体环节。技术有章法，服务有回应，把技术问题说明白，把交付过程做清楚，才能让图片在不同设备上都稳定呈现。
