一张AVIF图片在电脑浏览器里打开正常，换到部分安卓手机的旧版WebView上却只剩一块空白，连破图图标都不显示。遇到这种情况，很多人第一反应是图片坏了，于是反复重新上传，结果依然如故。问题往往不在文件本身，而在于承载图片的WebView容器能不能解码AVIF。这两件事必须先分开：文件是否有问题，容器是否具备解码能力。方向不同，排查路径也完全不同。
先看图片文件这一层。AVIF基于AV1编码，和常见的JPEG、PNG不是同一套机制。把文件下载到本地，用系统属性或命令行工具确认实际编码格式、位深和色域标记，再核对扩展名与真实格式是否一致。实际工作中存在把其他格式直接改成avif后缀的情况，浏览器按扩展名或Content-Type判断后交给解码器，自然无法成功。高位深或特殊色域标记的图片也要留意，部分旧解码器支持范围有限，可以导出一份标准位深的版本做对照测试。
再看服务端这一层。如果站点使用内容协商，依据请求头里的Accept字段决定返回AVIF还是回退格式，就要确认旧WebView发出的Accept是否包含AVIF标识，服务端是否按要求正确返回。同时检查缓存策略，避免同一地址把旧格式与AVIF混存，导致部分设备拿到不匹配的内容。使用CDN时，还要确认边缘节点没有改写Content-Type，把image/avif标成其他类型，解码器会直接放弃处理。
接着看前端与容器这一层。安卓WebView的解码能力取决于系统WebView内核版本，不同机型、不同系统版本差异明显。可以打开调试工具查看内核版本，并确认页面是否提供了降级路径。使用picture标签时，source的顺序与type声明要准确，浏览器会按顺序挑选第一个支持的来源；顺序写反或type写错，支持AVIF的设备可能拿到回退图，不支持的设备反而拿到AVIF。也可以用脚本探测解码能力，再决定加载哪种格式。
可执行的核对清单如下：一是确认文件真实编码与扩展名一致；二是核对服务端内容协商与缓存键；三是检查CDN是否改写响应头；四是确认WebView内核版本与picture标签写法；五是统一提供JPEG或WebP回退，并记录每次加载失败的机型与内核信息。上线前用目标机型抽测，比在电脑上反复刷新更有意义。
把格式兼容核对固定进上传与发布检查，问题就不会拖到用户端才暴露。it数运在网站维护中更强调把问题分层说明白：文件层、服务端层、容器层各查什么，先有顺序，再有结论，处理起来才稳定。技术有章法，服务有回应，把技术问题说明白，把交付过程做清楚，正是日常维护中值得坚持的做法。
