高清图导出前先看文件：Pillow 区分动画和静态素材

　　高清图导出前先看文件要处理的不是商品效果，而是一类可以由程序明确判断的输入问题。Pillow打开素材后读取n_frames；静态素材只有一帧，动画进入单独流程。例子在临时目录创建一张PNG和两帧GIF，并拒绝把GIF当成单帧交付。

输入契约与实现

　　Pillow打开素材后读取n_frames；静态素材只有一帧，动画进入单独流程。例子在临时目录创建一张PNG和两帧GIF，并拒绝把GIF当成单帧交付。

　　代码把多帧素材分流限定成小范围任务，刻意不增加网络请求、文件覆盖和发布动作。

运行结果与排错

　　静态PNG返回24×16尺寸；两帧GIF返回animated:2错误。夹具由本地代码新建，不使用商品素材也不调用生图接口。

　　只检查帧数与解码，不检查动效含义。真实项目若需要动画，应单独导出与预览，而不是默认丢掉后续帧。如果要扩大范围，先添加对应失败夹具，再修改实现。

　　成功分支同样要验证结果含义。

放在图片制作链路的哪里

　　这个工具适合放在动画检查工具相关的本地资料整理环节，和图像制作保持解耦。

　　实际交接至少保留输入版本、代码版本和完整报告。

　　本例的覆盖范围是：静态PNG返回24×16尺寸；两帧GIF返回animated:2错误。夹具由本地代码新建，不使用商品素材也不调用生图接口。未覆盖的边界是：只检查帧数与解码，不检查动效含义。真实项目若需要动画，应单独导出与预览，而不是默认丢掉后续帧。

from pathlib import Path
from tempfile import TemporaryDirectory
from PIL import Image
import json
def inspect(path):
    with Image.open(path) as image:
        frames = getattr(image, 'n_frames', 1)
        if frames != 1:
            raise ValueError('animated:' + str(frames))
        image.load()
        return {'size': list(image.size), 'mode': image.mode}
with TemporaryDirectory(dir=Path(__file__).resolve().parent) as folder:
    root = Path(folder)
    a = Image.new('RGB', (24, 16), 'red')
    b = Image.new('RGB', (24, 16), 'blue')
    a.save(root / 'static.png')
    a.save(root / 'motion.gif', save_all=True, append_images=[b], duration=100, loop=0)
    success = inspect(root / 'static.png')
    assert success['size'] == [24, 16]
    try:
        inspect(root / 'motion.gif')
    except ValueError as exc:
        error = str(exc)
        assert error == 'animated:2'
    else:
        raise AssertionError('expected animated rejection')
print(json.dumps({'success': success, 'error': error}))

编辑复核与下一组测试

　　这里的PNG与两帧GIF夹具是在区分素材应进入哪条交付流程，而不是比较两种格式的画质。静态PNG返回24×16，只说明该素材按本例取得了单帧尺寸；这个数字显然不能作为高清或4K交付已经达标的依据。两帧GIF返回animated:2时，报告中的2应读作检测到的帧数，不是第二张图片的编号，也不是让操作者只保留第一帧的操作指令。处理这一分支，应先问素材负责人是否需要保留动作变化：若后续帧展示了商品另一角度、状态切换或文字变化，静态交付就需要重新选定信息范围；若项目要求动画，应转入另行导出与预览的流程，不能在静态检查器里默认抹掉后续帧。帧数检查尤其适合放在素材收集结束、静态版面开始排版之前，避免设计人员按照首帧做好版面后才发现原素材还承载其他信息。交接记录可分别注明原文件、检测帧数和最终采用静态或动画的决定，让接收者知道animated:2是待分流对象，而不是损坏文件。下一组测试可以加入单帧GIF，与现有两帧GIF对照，检验判断依据是否确实来自n_frames，而非扩展名；也可加入三帧素材，确认错误中的帧数随输入变化，而不是固定输出两帧示例的文本。若继续考虑其他可含多帧的格式，应先制作对应夹具并确认解码支持，不能只凭文件后缀套用现有GIF结论。还应把无法打开的文件与能够打开但帧数大于一的文件分开记录，前者需要查文件本身，后者需要确定交付形式，两类问题不宜合并成素材不可用。对于通过检查的单帧文件，后续仍应独立核对目标宽高、缩放方式和版面裁切，因为一帧只回答是否存在后续帧，不能回答放大后细节是否足够。对于被拒绝的动画，另行预览应关注帧间变化与播放结果，当前工具并不判断动效表达是否完整。保留24×16成功夹具和animated:2拒绝夹具的意义，是让下一位维护者能够区分静态接受与动画分流这两个明确目标，不把标题中的高清导出误解成代码已经承担分辨率提升或动画转静态的职责。