页面里那张WebP图不动，只停在第一帧，刷新没反应，换台电脑或换个浏览器偶尔又能正常播放——这种情况在维护群里经常被一句“图坏了”带过。但动画WebP只播一帧，真正的原因可能藏在文件、转码、前端渲染和终端兼容这四个环节里。与其反复重传，不如按顺序逐层排查。
第一层：先看文件本身是不是真的动画WebP
静态WebP和动画WebP用的是同一个扩展名，光看文件名根本分不出来。最直接的办法是把文件拖进浏览器新标签页打开：画面动起来，说明文件里确实包含动画帧序列；如果还是静止，那它可能本来就是一张静态图，只是来源或命名让人误以为它是动图。看体积也能辅助判断，动画WebP通常比同尺寸静态图大不少，但这只能当参考，不能当唯一标准。更稳妥的做法是用能查看帧信息的工具打开，确认里面是否存在多帧结构和循环标记。
第二层：核对服务端转码有没有保留帧序列
文件确认没问题后，下一步就看上传流程里的转码环节。很多系统会对图片做压缩、裁剪或格式转换，如果转码时只取了第一帧，后面前端怎么写都不会动。常见的情况有：转码参数按静态图处理，输出时把后续帧丢了；压缩工具不支持动画WebP，静默降级成静态输出；缩略图生成逻辑和原图处理逻辑混在一起，把动图当普通图处理。核对方法是直接访问上传后的原始文件地址，看它是否还带有多帧信息，再和转码后的输出文件对比。两边不一致，问题就出在转码环节。
第三层：检查前端是不是用支持动画的方式渲染
图片标签和画布方式的处理逻辑不一样。用图片标签直接引用WebP，浏览器通常能自动播放动画；如果页面通过画布绘制图片，而绘制时只取了一帧，动画就会停在第一帧。另外，有些前端库会对图片做统一预处理，把动图转成静态位图再渲染。核对时可以临时用最简页面直接引用该文件，排除框架和组件的干扰，确认问题是否出在渲染层。
第四层：确认浏览器和终端兼容范围，准备静态兜底
不同浏览器、不同系统版本对动画WebP的支持程度存在差异，部分环境只解码第一帧，甚至完全不支持。实际做法是渐进增强：优先使用动画WebP，同时准备一张静态封面图作为兜底，通过特性检测决定加载哪一种。这样即使终端不支持动画，用户也能看到完整画面，而不是空白或破图。
把这四层整理成核对清单：第一层看文件是否真为动画WebP，第二层看服务端转码是否保留帧序列，第三层看前端是否用支持动画的方式渲染，第四层看终端兼容并准备静态兜底。it数运在网站维护中通常按这个顺序排查，先排除文件问题，再检查转码链路，然后验证前端渲染，最后处理兼容与兜底，避免在错误环节反复调整。技术有章法，服务有回应，把问题说明白，交付过程才能做清楚。
