有用户反馈，上传的动图在网页端打开后只剩一张静止画面，既不动也不报错。这类问题常被误判为图片损坏，其实文件往往完好。需要先区分格式：普通PNG是单帧静态图，GIF支持多帧动画但色彩表现有限，APNG则是在PNG结构上扩展出多帧动画能力，画质更好，但支持情况并不一致。网页端只显示第一帧，多数是链路中某一环把它当成了普通PNG处理。排查可以按以下四层推进。
第一层，核对文件本身。先确认扩展名与实际编码是否一致，有些文件名为png，实际是改了后缀的GIF或其他格式，浏览器会按真实编码解析。再确认它确实是多帧APNG，而不是一张静态图被误传。可以用支持查看帧信息的工具打开，看是否存在多帧数据和动画控制块。如果文件本身只有一帧，问题不在网页端，而在素材源头。
第二层，核对浏览器支持。不同浏览器对APNG的支持程度不同，有的完整播放，有的只渲染第一帧作为降级表现，还有的会直接按静态PNG显示。同一张图在不同浏览器、不同版本里表现可能不一样，因此要在目标用户常用的浏览器上分别验证，而不是只在自己电脑上看一次。具体支持情况以各浏览器官方文档为准。
第三层，核对上传与转码链路。这是最容易被忽略的一环。很多网站会对上传图片做压缩、缩放或格式统一，图片处理服务若只识别PNG而不识别其动画扩展，就会把多帧图压成单帧静态图，前端拿到的已经是残图。需要检查上传后服务器上的实际文件，与用户原始文件对比帧数和体积，确认转码参数是否保留了动画信息。
第四层，核对前端渲染方式。用img标签直接引用和用背景图引用，表现可能不同；部分懒加载组件、图片裁剪组件或CDN的自动优化功能，也会在中间环节丢弃动画帧。可以临时用最朴素的方式直接引用原图，排除组件干扰，再逐步加回原有逻辑，定位是哪一层改变了文件。
给一份可执行的排查顺序：先看原始文件是否多帧，再看服务器留存文件是否仍多帧，接着在目标浏览器直接打开该文件地址，最后检查前端引用方式与中间组件。若短时间内无法修复，可临时转成GIF保证可播放，或保留静态首帧并附上原图链接，先不影响页面使用。
维护记录里应保留用户原始文件、上传后的文件以及转码参数，便于后续对比定位。it数运在处理此类维护问题时，也按文件、浏览器、转码、渲染四层留痕，避免同类问题反复出现。
