同一张WEBP动图在聊天工具里播放正常，嵌入网页后却始终只显示第一帧，刷新页面、更换设备都没有改善。遇到这种情况，不少人第一反应是浏览器出了故障，或者图片文件损坏，但真正的原因通常分布在文件、浏览器、页面实现和服务端处理四个层面。维护人员如果一开始就动手改代码，很可能做了大量无效工作。更稳妥的方式是先判断问题落在哪一层，再决定修改什么。
先核对文件本身
把原图下载下来，用能够查看图片信息的工具确认它究竟是动态WEBP还是静态WEBP，重点查看帧数、循环次数和总时长。有些文件扩展名是webp，内容却只有一帧，用户以为上传的是动图，实际传的是截图或导出时选错了格式。同时要确认上传环节有没有被自动转码，部分后台为了统一尺寸会重新生成图片，转码过程中把多帧压成了单帧。这一步不确认清楚，后面的排查都没有意义。
再核对浏览器解码能力
动态WEBP在不同浏览器和不同版本上的支持程度并不一致，较旧的版本可能只解出第一帧而不报错。可以做一个简单对照：新建一个空白页面，只放这张图，不加任何样式和脚本，分别在用户使用的浏览器、另一款主流浏览器和手机端打开。如果空白页能播放，说明浏览器本身没问题，问题在页面环境；如果空白页也只显示第一帧，就要怀疑浏览器版本或文件本身。
接着核对页面写法
检查图片标签是否被替换成了背景图，背景图在某些情况下不会播放动画。检查样式里有没有固定宽高比、裁切或滤镜，这些一般不影响播放，但过度压缩尺寸可能让动画看起来像静止。还要看脚本是否在加载后对图片做了二次处理，比如替换地址、生成缩略图、套用懒加载组件。懒加载组件如果只取第一帧做占位，用户看到的就永远是第一帧。逐项关掉脚本和样式做对比，能快速定位是哪一段写法覆盖了动画。
最后核对服务端处理
图片上传后常经过压缩、生成缩略图、CDN缓存转换等环节，其中任何一步把动图当静态图处理，前端拿到的就已经是单帧文件。可以绕过页面直接访问图片原始地址，对比上传前后的文件信息，看帧数是否变化。如果原始地址已经是单帧，问题就在服务端，需要调整压缩策略或对动态图单独放行。
实际排查可以按文件、浏览器、页面、服务端的顺序逐项确认，每一步都留下对比结果，避免反复猜测。it数运在处理此类网站维护问题时，通常也是先固定证据再动配置，减少来回改动带来的新问题。需要说明的是，浏览器版本和平台策略会持续变化，具体表现应以实际测试和官方说明为准。如果一时无法确认根因，向用户说明当前已排除的环节和仍需观察的范围，比给出一个不确定的结论更负责。
