有客户反馈，页面上放了一张GIF动图，打开网页后只动了一次就停住，看起来像一张静态图。这类问题在网站维护中很常见，但原因并不单一。GIF在网页端的播放行为，同时受文件本身、浏览器处理方式和页面代码三方面影响。只盯着其中一个方向查，往往反复修改也找不到根源。下面按从文件到页面的顺序，分层核对。
第一层，先看文件本身。把GIF下载到本地，用系统自带的图片查看器或浏览器直接打开。如果本地打开也只播一遍，说明问题出在文件里，与网页无关。重点看三个地方：一是帧数，有些文件看着是动图，实际只有两三帧，播完就结束；二是循环次数标记，GIF文件头里有一个循环播放次数的设置，如果被设为只播一次，任何浏览器都只会播一遍；三是帧延迟，部分制作工具导出的帧延迟异常，播放会显得卡顿甚至提前停住。另外留意文件体积，过大的GIF在网页上可能被加载策略截断，表现也是播到一半不动。
第二层，核对浏览器与页面加载方式。同一张GIF，在不同浏览器里表现可能不同。可以换两三个浏览器对比，如果只有一个浏览器异常，多半是加载或缓存问题。还要确认图片是否经过了压缩或转码服务。有些网站为了提速，会把图片交给第三方压缩工具处理，部分工具会把GIF转成静态图或只保留首帧，上传的是动图，页面上拿到的却是静态版本。核对方法是直接访问图片的原始地址，看返回的文件类型和大小是否与上传时一致。
第三层，核对前端代码。图片在页面里通常有两种用法：img标签直接引用，或作为背景图写在样式里。背景图方式下，部分浏览器对循环行为的处理与img标签不同，容易出现只播一次的情况。还有一种情况是页面脚本在图片加载后做了替换，比如懒加载逻辑把动图换成了首帧占位图，或者某些优化脚本主动冻结了动画。核对时可以在浏览器开发者工具里查看最终渲染的图片地址，确认它是不是原始GIF文件。
排查时可以按这份清单记录：本地打开是否循环、文件循环次数标记、文件体积与帧数、不同浏览器表现、图片最终访问地址、页面中的引用方式。每一项都记下结果，问题定位会快很多。
修改后如何验证？清空浏览器缓存，换一台设备再打开页面，观察动图是否持续循环，同时确认页面加载速度没有明显变差。如果问题依旧，把上述记录连同GIF原文件一起提供给开发方，能省去大量来回沟通。it数运在网站维护中处理这类反馈时，通常也是先分清是文件问题还是页面问题，再决定改哪一头，避免盲目改动代码。
