图片格式协商失效时，页面往往不会立刻报错，而是表现为部分浏览器图片空白、下载成文件，或同一地址在不同设备上显示不一致。排查这类问题，建议按“协商—写法—缓存”三层顺序推进，避免一上来就改代码却漏掉真正原因。
第一层：核对服务端格式协商
先确认服务端是否根据请求头中的Accept字段判断浏览器能力，再决定返回AVIF、WebP还是JPEG。有些站点把AVIF地址直接写死在页面里，任何浏览器拿到的都是同一个文件，旧浏览器自然无法解码。核对方法是抓取一次旧浏览器的图片请求，观察响应头中的Content-Type和实际返回的文件后缀是否与预期一致。如果服务端没有做格式协商，就需要补充回退配置，让不支持的客户端拿到兼容格式。
第二层：核对HTML层写法
使用picture元素时，source标签的type顺序决定浏览器选择哪一种格式。顺序放错会让支持AVIF的浏览器也拿到低版本图片，或者旧浏览器跳过所有source后没有可用的img兜底。img标签必须保留，并指向一个通用格式的图片地址，这是最后的保险。核对时逐条检查source的type声明是否与实际文件格式一致，确认img的src不是空值，也不是另一个AVIF地址。
第三层：核对CDN与缓存
回退方案上线后，旧格式图片可能没有命中缓存，或者缓存里仍是旧的内容类型，导致浏览器拿到文件却无法识别。重点看CDN是否按文件后缀正确设置Content-Type，是否存在把JPEG响应头改写成其他类型的情况。修改配置后要主动刷新相关缓存，并用旧浏览器实际访问验证，不能只看新浏览器的结果。
上线前的确认清单
可以按一份简短清单逐项确认：整理目标浏览器的格式支持表，明确哪些版本需要回退；确定回退优先级，是JPEG优先还是WebP优先；检查picture与img的配合是否完整；验证服务端协商逻辑；刷新缓存后用真实旧环境测试。清单不必复杂，但要覆盖从请求到渲染的完整路径。
维护阶段的常规做法
先确认网站需要覆盖的浏览器范围，再决定AVIF是否作为主格式。如果访问群体中旧版本占比不低，保留AVIF的同时必须把回退链路做扎实；如果范围较新，也要保留img兜底，避免个别环境出现空白。it数运在网站维护中通常建议把格式支持范围写成简短文档，随代码一起更新，减少后续交接时的反复排查。图片显示问题往往不是单点故障，按协商、写法、缓存三层顺序核对，多数情况都能找到原因。
