聊天页里发出去一个GIF表情包，只闪了一下就停住不动，用户的第一反应通常是“这表情包坏了”。可从开发角度看，同一句反馈背后可能对应四种互不相同的成因：文件本身就只有一帧、上传环节被转成了静态图、消息渲染时没有触发播放、客户端缓存了旧版本。只改其中一层，往往会出现改完又坏、反复返工的情况。下面按从文件到客户端的顺序，逐层核对。
第一层，先确认GIF文件本身。把用户上传的原始文件取出来，用看图工具查看帧数是否大于一帧、循环次数是否为无限循环、每帧延迟是否被设成零或异常值。有些表情包在制作导出时就是单帧图，扩展名却仍然保留为gif。同时留意调色板和文件体积，部分客户端对动图设有大小上限，超出后可能只渲染首帧。核对时记录帧数、循环参数、单帧延迟和文件大小，这四项作为后续判断的基准。
第二层，核对上传与存储环节。常见情形是上传接口对图片做了统一压缩，而压缩工具不支持多帧，输出时只保留第一帧。另一种情形是服务端为列表页生成了静态缩略图，聊天页却错误地引用了缩略图地址。需要确认服务端是否保留原始文件、返回给前端的地址指向原图还是缩略图、压缩参数是否对gif做了特殊处理。如果存储层只存了一份处理后的文件，原始动图已经丢失，后面无论怎么调整渲染都无法恢复。
第三层，核对消息渲染与播放策略。查看聊天页使用的图片组件是否支持动图格式，部分组件默认按静态图加载。再检查循环参数是否被业务代码覆盖，例如统一设置成只播放一次。还要留意列表滚动时的优化逻辑，有些实现会在滚动过程中暂停动图播放，滚动停止后没有恢复，用户看到的就是定格画面。这一层要记录组件类型、循环设置和滚动时的播放状态。
第四层，核对客户端缓存与网络。旧版本图片被缓存后，即使服务端已经更新，客户端仍显示旧图。弱网环境下，部分加载策略会先显示首帧，等完整文件下载完再播放，如果下载中断就停在首帧。此外要确认CDN是否缓存了错误版本，可以通过带随机参数的地址对比验证。排查时记录缓存命中情况、请求返回的文件大小和实际渲染结果。
为减少来回沟通，可以按顺序执行一份排查清单：先取原始文件确认帧数与循环，再查上传接口的压缩日志，然后看渲染组件的动图支持与播放参数，最后清缓存换网络复测。每一层都留存文件信息、接口返回地址、组件配置和复测截图，形成记录表。这样即使问题跨团队，也能快速定位到具体环节。涉及具体平台对动图的格式和体积限制时，应以对应平台的官方文档为准。
