用户反馈的情况很具体：一张WEBP动图上传到网站后，页面里只动了一下就停住，看起来像是“播了一次”。这个描述要先和另外两种情况分开。完全不动，通常是文件没加载出来或格式不被识别；只显示第一帧，多半是处理环节只取了静态图。而“动一下再停”，说明动图确实被播放过，问题更可能出在循环参数、处理流程或缓存版本上。三种现象对应三条排查路径，混在一起查容易白费时间。
先做一个对照实验：把用户上传的原文件从后台下载下来，直接用浏览器打开。如果原文件在浏览器里能持续循环播放，说明文件本身没问题，重点转向网页端的处理链路；如果原文件也只动一次，那问题就在文件生成环节，需要回到制作工具检查导出设置。这一步能砍掉一半的排查范围，建议每次维护都先做。
接下来按四层核对。第一层看动图的帧数与循环参数。WEBP动图支持循环次数设置，有些导出工具默认只播放一次，或者循环次数被设成了有限值。可以用图片信息查看工具确认总帧数和循环标记，帧数过少也会让动画看起来“一闪就停”。第二层看网页端的图片处理流程。不少网站为了压缩体积，会对上传图片做缩略图或转码处理，如果处理程序只读取第一帧生成静态版本，前端引用的又是这个版本，就会出现动一下即停的现象。要确认页面实际加载的是原图地址还是处理后的地址。第三层看缓存与CDN。图片替换后，浏览器缓存或CDN节点可能仍保留旧的静态版本，表现就是新文件上传了但页面行为没变。核对时可以带上时间戳参数访问，或查看响应头里的缓存信息。第四层看浏览器差异。不同浏览器对WEBP动图的支持程度不完全一致，同一文件在甲浏览器正常、乙浏览器异常的情况确实存在，需要用两到三个主流浏览器交叉验证。
排查时建议按固定顺序记录：先记原文件直开结果，再记页面实际加载地址，然后记缓存状态，最后记各浏览器表现。每换一次文件都在记录里写清版本和时间，避免反复替换却说不清哪次有效。这套记录方式在it数运的网站维护实践中也常被用来缩短沟通成本，把现象描述清楚，后续处理才有依据。
修复后的回归验证不能只看“这次动了”。要确认动图能持续循环、页面刷新后行为一致、换浏览器仍然正常，同时检查图片体积是否影响加载速度。如果问题涉及第三方图片处理组件或CDN服务，具体表现和配置项应以对应服务商的公开说明为准，必要时请相关技术人员协助确认。把验证要点固定下来，下次遇到同类反馈就能直接套用。
