企业官网建设流程全解析

做动图这件事，坑基本都集中在三个地方：播放节奏跟原片对不上、颜色糊成一片还有一圈灰边、以及文件体积大得让页面加载直接卡住。很多人以为这是"GIF 格式就这样"，其实大部分问题是参数没调对、流水线没设计好，而不是格式本身的天花板。GIF 动图全链路控制这套东西，说穿了就是把帧精度、色深压缩、Web 兼容性这三块拆开，各自搞清楚约束条件，再在体积和观感之间找一个你能接受的点。这篇内容适合做产品演示图、操作录屏、表情包、文档配图的人看，不管你是用命令行工具批量出图，还是在前端做动图加载优化，下面的东西都能直接抄。我会把每一步为什么这么设、参数卡在哪个值、出问题怎么往回查都讲清楚，尽量少讲概念多讲能跑起来的东西。

1. 先弄清GIF的四个结构性约束，后面所有取舍都从这里推

1.1 延迟字段只有两个字节，时间精度被死死锁在10毫秒

GIF89a 里每一帧前面挂着一个图形控制扩展块，里面有个 Delay Time 字段，两个字节的无符号整数，单位是百分之一秒。这句话翻译过来就是：帧延迟只能是 10 毫秒的整数倍，没有更细的刻度。你想表达 33.3 毫秒一帧？对不起，只能填 3（30ms）或者 4（40ms）。这个约束看着不起眼，但它会直接导致一件事：从视频转 GIF 的时候，时间轴一定会漂移，转得越长漂得越厉害。

我见过不少人做的动图，播放十几秒之后和原视频差了小半秒，然后反复怀疑是工具 bug。不是，是精度不够。一帧差 3 毫秒，300 帧就差了接近 1 秒。所以正确的思路不是"让每帧都对"，而是让总时长对：把所有帧的延迟加起来，跟目标时长做对比，把误差摊到若干帧上去。比如目标是 8 秒、120 帧，理论每帧 66.67ms，实际只能填 7（70ms）或 6（60ms），那就按 2:1 的比例混填 70 和 60，总和控制在 8000ms 附近。

还有一个容易被忽略的点：Delay Time 是 2 字节，上限 65535，也就是 655.35 秒。做超长动图（比如几分钟的循环演示）时如果某帧想停顿很久，得分段处理，别指望一个值搞定。

1.2 每帧最多256个索引色，颜色预算是一次性消耗品

GIF 是索引色格式，每个像素存的是调色板下标，不是 RGB 值。调色板最多 256 项，这 256 项要同时承担整幅画面里所有的颜色。注意"同时"这两个字——它不是每秒 256 色，也不是每帧 256 色（局部调色板可以做到每帧独立，但体积代价很大），而是一整个色域被压缩到 256 个格子里。

这就是为什么渐变背景一转 GIF 就出环状色带，为什么皮肤过渡会变成一块一块的。不是压缩算法不行，是信息容量根本不够。你可以这么理解：给你 256 支颜料去画一幅写实油画，再厉害也只能画成风格化作品。所以做 GIF 的第一件事，是判断你的素材里有多少种颜色是"必须保留"的，哪些是可以牺牲的。纯色 UI 演示、代码录屏、线稿动画，256 色绰绰有余；实拍视频、渐变海报、光影丰富的三维渲染，256 色一定不够，只能靠抖动去骗眼睛。

额外提醒一句：如果你用了透明色，那 256 个格子里有一个要被透明索引占掉，实际可用颜色是 255 个。这个细节在后面讲边缘发灰的时候还会提到。

1.3 LZW对"重复"敏感，画质优化经常直接把体积顶上去

GIF 用的压缩是 LZW，一种基于重复模式的字典压缩。它的特点是：画面里相同的像素串越多，压得越狠；画面越"花"，压得越差。这就带来一个反直觉的结论——抖动虽然让画面看着更平滑，但会让体积暴涨。因为抖动本质上是在相邻像素之间制造随机噪点，而随机噪点恰恰是 LZW 最讨厌的东西。

我做过一组对照：同一段 720p 十秒素材，不抖动输出 2.1MB，加上 Floyd–Steinberg 抖动直接干到 7.8MB，接近四倍。画质确实好了，但如果你是要放在首屏的展示图，这四倍可能就不能接受。所以抖动不是一个"开或关"的开关，而是一个需要和尺寸、帧率一起权衡的成本项，后面第 4 节会具体给组合策略。

1.4 差分帧与处置方式：体积优化的另一半

GIF 支持只更新画面中变化的部分，这叫差分帧（也叫局部更新）。原理是：每帧可以只描述一小块矩形区域，其余像素用透明索引标记为"保持不变"。对于鼠标移动、文字逐行出现这类动效，差分帧能把体积压到全帧的三分之一甚至更低。

但差分帧要和处置方式（Disposal Method）配合。处置方式决定了这一帧画完之后，下一帧来之前这块区域怎么处理：不处置（保留）、恢复背景色、恢复上一帧。选错了会出现残影、拖尾、闪烁。我踩过最典型的一次：录屏演示里有一个半透明蒙层淡入，用了"不处置"的差分帧，结果每一帧的蒙层都叠在上一帧上面，播到后面整块变成纯灰。

差分帧不是万能的。素材里有大面积渐变、噪点、镜头运动的时候，帧间差异大，差分反而会引入大量小矩形块，体积不降反升，还可能出现块状撕裂。判断标准很简单：变化区域占全画面 60% 以上就老老实实全帧。

2. 帧精度：把播放节奏当时间轴设计，而不是数帧数

2.1 24、25、30fps落到GIF上会发生什么

先说结论：GIF 不存在真正的 30fps。30fps 意味着每帧 33.33ms，而 GIF 只能填 30ms 或 40ms。填 30ms 实际是 33.3fps，填 40ms 是 25fps，两者都不对。所以做 GIF 的时候，比较靠谱的做法是主动选那些能被 10 整除的帧率：

25fps 和 20fps 是两个甜点。25fps 观感接近流畅，体积可控；20fps 对演示类内容完全够用，体积还能再省 20% 左右。至于电影感的 24fps，落不到整数上，硬转会累积漂移，除非你手动做误差补偿。

具体怎么补偿？假设源是 24fps、总时长 10 秒、共 240 帧。目标延迟理论值 41.67ms。可以按 4、4、4、5、4、4、4、5……这样一个 8 帧循环去填，让每 8 帧的总延迟等于 8×41.67≈333ms，实际填充 4×6+5×2=34，也就是 340ms，每秒 3 个循环，累计误差 20ms/秒。再细一点就用 25 帧循环做补偿，误差能压到 5ms/秒以内。手写这个映射不现实，得靠脚本算，但思路就是这个思路——用不均匀延迟去逼近均匀时间轴。

2.2 延迟填0和填1，各家浏览器会给你"惊喜"

这是 GIF 最经典的兼容性陷阱，值得单独拎出来说。图形控制扩展里，延迟值填 0 或者 1（也就是 0ms 和 10ms），很多浏览器实现会认为"这个值太小了，是制作者写错了或者想跑满帧"，于是自动把它提升到 100ms 播放。也就是说，你精心设计的 100fps，最后会变成 10fps，慢十倍。

这不是某一个浏览器的怪癖，而是多年来为了防 CPU 被打满形成的惯例，桌面端和移动端的具体阈值不完全一致，但 0 和 1 基本都中招。所以有两条硬规矩：

• 延迟值不要低于 2（20ms，也就是 50fps 上限）。超过 50fps 的动图本身也没什么意义，正常内容用不到。
• 需要"停顿"效果时，不要用超长延迟，而是额外插入一帧与前一帧完全相同的画面，单独给它一个较长延迟。有些解码器对超过几百毫秒的单帧延迟处理不一致，插重复帧更保险。

2.3 变速、停顿、首帧停留的工程做法

动图不是只能匀速播。演示类内容经常需要"快速切入，关键步骤停两秒，再快速结束"。这类节奏在制作阶段就要规划，而不是出图之后改。

具体做法是给每帧单独指定延迟，而不是全局一个值。我通常按"段落"来分配：开场动画 40ms/帧，操作过程 80ms/帧，结果展示那几帧给 1500ms 让观众看清楚。用命令行工具处理时，可以把延迟列表做成一个文件或者直接拼在参数里，帧数不多的时候手写也没问题。

首帧停留是个特殊场景：微信、社群、文档里展示动图，很多平台只显示第一帧作为封面。所以第一帧必须是信息量最大、最能说明问题的那一帧，不能是黑屏、不能是空白、最好也别是动画的起始状态。我习惯在开头插一帧完整状态的画面，延迟给 800ms 到 1200ms，既能当封面，又能让观众先看清楚全貌再看过程。

2.4 出图之后一定要把延迟表读回来核对

这一步很多人跳过，然后在上线之后发现节奏不对，回头查半天。其实用一个命令就能把每帧的延迟、尺寸、处置方式全部导出来。养成习惯，出图必查，尤其是批量处理的时候。

# 逐帧导出延迟、尺寸、偏移、处置方式 identify -format "%s: %T ms %wx%h offset=%X,%Y dispose=%D\n" output.gif # 汇总总时长（毫秒） identify -format "%T\n" output.gif | awk '{s+=$1} END {print "total:", s, "ms"}'

导出之后对两件事：总时长是不是接近目标值，有没有哪一帧的延迟是 0 或 1。第二件事特别重要，因为有些不规范的工具在转换时会默认写 0，肉眼看不出来，一上浏览器就露馅。

3. 色深压缩：256色不是画质差，是预算怎么分配

3.1 量化算法怎么选，中位切分和八叉树差别在哪

把真彩色降到 256 色这一步叫量化（quantization），常见算法有中位切分（median cut）、八叉树（octree）、以及 k-means 这类聚类方法。它们的思路不太一样：

• 中位切分：把颜色当成三维空间里的点，沿最长的轴反复对半切，切到 256 个盒子，每个盒子取平均色。它倾向于让每个调色板颜色覆盖差不多数量的像素，对色彩分布均匀的图效果好。做动图的时候这是默认首选。
• 八叉树：把 RGB 空间做成树结构，逐层合并相似颜色。它对内存友好、速度快，但对大面积单色加小面积高饱和的图（比如深色背景加一个亮色按钮）容易把亮色丢掉。
• k-means 类聚类：质量最好，但慢，而且结果受初始值影响。批量出图时不划算。

实操上来说，动图的量化跟静态图有个关键区别：你是在给一整段动画选一套配色，不是给某一帧。如果逐帧独立量化，帧与帧之间的调色板会跳，播放时背景颜色会轻微闪烁，观感极差。正确做法是先把所有帧的统计信息汇总，生成一套全局调色板，再让每一帧都用这套板子去映射。多数工具都提供了"统计模式"参数，专门用来做这件事，其中还有一个"只看差异区域"的选项，能避免调色板被大片静止背景带偏——这个细节后面第 6 节会写具体用法。

3.2 抖动是拿体积换平滑，得算清这笔账

抖动（dithering）的本质是用相邻像素的颜色混合，在视觉上模拟出调色板里没有的颜色。两种主流方案：

• 误差扩散（Floyd–Steinberg、Sierra 系列）：把当前像素的量化误差按权重分给周围未处理的像素。效果最自然，但产生大量随机噪点，LZW 压缩率断崖式下跌，体积通常涨 2 到 4 倍。
• 有序抖动（Bayer）：用固定的矩阵做阈值，产生规则的网点纹理。观感上像报纸印刷，不如误差扩散自然，但图案规则、重复性强，压缩率好得多，体积涨幅通常在 30% 到 80%。而且它有个隐藏优点：不会在帧与帧之间产生"噪点游动"，误差扩散在动态画面里噪点每帧都不一样，播放时会有明显的"沙沙"感。

我的经验分界线是这样的：纯色扁平插画、UI 演示、线稿，直接关抖动，256 色完全够，一点问题没有；有轻微渐变的图标和阴影，用 Bayer 加低强度（缩放系数 3 到 5），体积增加可接受；实拍或三维渲染的渐变背景，如果一定要用 GIF，才上误差扩散，同时把尺寸砍一半来换体积。

有个判断技巧：如果你发现加了抖动之后，体积涨了 3 倍以上但观感提升不明显，说明你的素材本身颜色种类并不多，只是渐变区域有点色带。这种情况下把抖动关掉、把颜色数从 256 降到 128 甚至 64，观感几乎没变化，体积能省一半。

3.3 局部调色板值不值得用

GIF 允许每一帧带自己的局部调色板，覆盖全局调色板。理论上这能大幅提升画质——每帧都有 256 色可用。但代价很直接：每帧要额外存 768 字节的调色板数据（256×3），100 帧就是 75KB 纯开销，而且相邻帧调色板不一致会导致颜色闪烁。

真正适合用局部调色板的场景很窄：帧数少（比如 10 帧以内的关键帧动画）、而且每帧的色调差异极大（一帧冷色夜景、一帧暖色室内）。这种情况下局部调色板能把两种色调都还原好。除此之外，全局调色板加差异帧的组合几乎总是更优。

补充一个折中方案：把动画拆成几段，每段用一套独立的全局调色板，段与段之间用一次"重置"来切换。这样既避免了逐帧调色板的开销，又能应对色调突变。缺点是拼接处可能会有一次轻微的色偏跳变，需要在剪辑阶段就选好切点，尽量切在画面全黑或者大色块切换的位置。

3.4 透明色索引与边缘发灰发黑的真实根因

动图边缘一圈灰边、黑边、粉边，这是被问得最多的问题，根因有两个，都跟透明色有关。

第一种：半透明像素没有地方放。GIF 的透明是"全有或全无"的——一个像素要么完全透明，要么完全不透明，没有 50% 这种中间态。所以当你的源素材（比如带羽化边缘的图标、带阴影的文字）有半透明像素时，转换工具必须做二选一：要么把它变成不透明（边缘变硬、出现锯齿），要么把它变成全透明（边缘被啃掉一圈）。更糟的是，很多工具在合成时会把半透明像素跟黑色做混合，于是你在白色背景上就看到了一圈灰黑边。

解决办法是：在转换前手动把半透明像素合成到你实际使用的背景色上。如果你的动图要放在白色页面里，就先在源素材里铺一层白色底再导出；要放在深色页面里，就铺深色底。这一步必须在进入 GIF 编码之前完成，编码之后再改就来不及了。

第二种：透明索引和调色板第 0 项冲突。有些编码器默认把调色板的第 0 项设为透明索引，如果你的画面里刚好有一个颜色被量化到了第 0 项，那块区域就会莫名其妙变透明。排查方法是把动图放到一个高对比度背景（比如品红色）上播放，看有没有不该透明的地方漏出来。

还有一个隐蔽的坑：浏览器渲染透明 GIF 时，透明区域显示的是页面背景色，不是白色。你在图片编辑器里看到的是白底，实际放到深色主题页面上，边缘那圈抗锯齿像素会跟深色背景打架，看起来像毛边。这就是为什么同一个动图在浅色页面好看、在深色页面难看。稳妥做法是干脆不用透明——直接把背景做成跟页面一致的颜色。虽然牺牲了通用性，但视觉上最可控。

4. 体积控制：把参数当多维空间，别挨个试

4.1 三个成本项的量级关系，先搞清楚谁最贵

GIF 的体积大致由三个因子决定：像素总数（宽×高）、帧数、每帧的信息熵（受颜色数和抖动强烈影响）。它们不是简单的线性叠加，但有个大致的量级感知很有用：

• 尺寸减半，体积大约降到四分之一。因为像素数是平方关系。这是最有效的杠杆，没有之一。
• 帧数减半，体积大约减半。但要注意，减帧会改变播放速度，必须同时调整延迟来保持时长不变。
• 颜色数从 256 降到 64，体积通常降 30% 到 50%（扁平素材降得更多，实拍素材降得少）。
• 抖动从开到关，体积降 50% 到 75%。这是第二大杠杆。

所以优化顺序应该是：先砍尺寸，再决定抖动，然后调帧率，最后才动颜色数。很多人反过来，先把颜色数从 256 调到 32，结果画面惨不忍睹，体积只降了一点点。

4.2 尺寸、帧率、颜色数、抖动的组合实验

给一组我实际测过的参考数据。素材是一段 8 秒的软件操作录屏，原始分辨率 1920×1080，画面以纯色背景和文字为主，带少量鼠标移动和窗口切换动画。用同一套编码参数，只改单一变量：

从这组数据能看出几个规律：尺寸从 960 降到 720（面积降 44%），体积降了 42%，基本吻合平方关系；颜色数减半降了 26%，比预期少，因为这类素材本身颜色就少，256 色里有一大半是浪费的；加 Bayer 抖动直接翻倍，比颜色数的影响大得多。

如果是实拍素材，结论会更极端：同样 960×540、20fps、256 色，不抖动大约 6MB，开误差扩散能到 20MB 以上。这种情况下 GIF 基本不是正确选择，应该考虑第 5 节讲的替代格式。

4.3 有损优化的副作用，别在不该用的地方用

现在有些工具提供"有损 GIF 压缩"，原理是允许相邻像素之间有一定误差，通过把相近的颜色合并成透明、让解码器用前一帧的像素填充，来提升压缩率。参数一般是个 0 到 200 的数值，越大压得越狠。

这东西确实好用，能让体积再降 30% 到 50%，但它有两个明确的副作用需要提前知道：

一是边缘撕裂。因为它靠"透明像素 + 前面帧填充"来省数据，在快速运动的物体边缘，填充可能对不上，出现锯齿状的拖影或者闪烁的小碎块。静态画面看不出来，一播放就明显。

二是对文字极其不友好。小号文字的笔画只有一两个像素宽，有损优化很容易把笔画啃掉一部分，导致文字发虚、断续。演示类动图里文字是核心信息，这种情况下有损参数建议不要超过 30，或者干脆不用。

我的用法是：先做无损优化（重新计算差分帧、合并相同帧、裁剪画布），跑一遍看体积；如果还差一点，再叠加一个低强度的有损，然后逐帧检查运动区域和文字区域，不能只看第一帧。

4.4 优化工具的层级关系，先做什么后做什么

工具链的顺序会影响最终结果，这点经常被忽略。正确的顺序是：

1. 裁剪画布：把画面里完全不变的外围区域裁掉，或者把多帧的共同边界收紧。这一步纯赚，不影响画质。
2. 缩放：一次性缩放到目标尺寸，用高质量重采样（Lanczos 之类）。不要先编码再缩放。
3. 降帧 + 时间重映射：按前面的方法重新计算延迟表。
4. 量化 + 抖动：生成全局调色板，映射所有帧。
5. 帧间优化：重新计算差分帧、合并完全相同的连续帧、把不变区域设为透明。
6. 有损优化（可选）：低强度叠加。
7. 校验：读回延迟表、体积、帧数。

顺序反了会怎样？比如先做帧间优化再缩放，缩放会把优化出来的透明区域重新变成实色，前功尽弃；再比如先量化再降帧，被删掉的帧的调色板统计信息就浪费了。我见过有人先有损压缩再缩放，结果撕裂被放大到整个画面。

5. Web端：加载、解码与降级，GIF从来不是孤立存在的

5.1 img标签自动播放，代价是控制权全丢了

把 GIF 塞进<img>是最省事的做法，浏览器自动播放、自动循环、不需要任何脚本。但这也意味着你失去了所有控制：不能暂停、不能跳帧、不能根据滚动位置决定播不播、不能根据用户偏好关掉动画。用户能做的只有等它播完，或者关掉页面。

真需要控制的话，有几条路：

• 换播放器方案：用<video>标签承载转码后的视频，autoplay muted loop playsinline四个属性一起上，就能实现类似 GIF 的自动循环播放，而且能调playbackRate、能暂停、能监听事件。体积还小一个数量级。这是目前最推荐的路线。
• 多帧图 + Canvas 手绘：把每一帧拆成独立的图，用脚本按时间轴往 canvas 上画。控制粒度最细，但实现成本高，而且要自己处理预加载和内存。
• 动图 WebP 或 APNG：格式本身支持动画，但控制能力跟 GIF 差不多，主要收益是体积和画质。

如果只是想在鼠标悬停时才播放，有个老技巧：<img>平时加载一张静态首帧，悬停时把src换成动图。缺点是首次悬停会有加载延迟，可以提前用<link rel="preload">或者隐藏的<img>预热。

5.2 体积和首屏：占位、懒加载与解码开销

GIF 的解码开销比大多数人想得大。它是逐帧解压 LZW、逐帧合成，没有硬件加速，全程吃主线程。一张 5MB、200 帧的动图在低端移动设备上解码，占用几百毫秒的主线程时间很正常，表现就是页面滚动卡顿、动画掉帧。

几条实用措施：

第一，永远给<img>写上明确的宽高属性。不是为了样式，是为了让浏览器在图片加载前就预留好空间，避免布局抖动。动图的尺寸往往不小，一次抖动可能把用户正在点的按钮推走。

第二，非首屏的动图一律懒加载。用loading="lazy"或者在滚动接近时再设置src。这里有个细节：loading="lazy"对动图的行为是"进入视口附近才开始下载"，但下载完就自动播了，用户可能只看到后半段。如果在意这个，就用手动方案——先放一张静态首帧当占位，进入视口后再换成动图。

第三，控制同屏动图数量。一个页面同时播五个动图，解码压力是叠加的。我一般会让同屏最多两个在播，其余的滚动到可见区域再启动，离开就换回静态图。用IntersectionObserver实现，代码量很小。

5.3 格式选型：什么情况下不该用GIF

这是最该讲清楚的一节。GIF 的唯一不可替代优势是兼容性——任何能显示图片的地方都能显示它，包括各种富文本编辑器、邮件客户端、聊天软件。除此之外，它在所有维度上都被现代格式超越了：

选型判断可以按这个顺序走：如果动图时长超过 5 秒、分辨率超过 640 宽、或者颜色复杂（实拍、三维、渐变），优先考虑视频，体积能小十倍以上；如果需要透明背景且动效简单，动图 WebP 是性价比最高的；如果目标环境只认 GIF（比如某些富文本编辑器），那就老老实实按前面的方法把参数压到极致。

有个混合方案我用得很多：<video>里同时放视频源和 GIF 作为兜底，不支持的浏览器自动回退。或者用<picture>配合type属性做格式协商，能支持 WebP 就给 WebP，不支持就给 GIF。这种方式对旧环境友好，又不牺牲新环境的性能。

5.4 可访问性：给不想看动画的人一个开关

这一点经常被完全忽略。动图自动播放、无限循环，对某些用户来说是真实的不适来源，连续闪烁的内容还可能引发不适反应。系统层面是有偏好设置的——用户可以在操作系统里声明"减少动态效果"，前端可以用媒体查询读到：

@media (prefers-reduced-motion: reduce) { .animated-figure { /* 换成静态首帧 */ content: url("./first-frame.png"); } }

用<img>的话 CSS 换图不太好使，更稳的做法是在脚本里判断：

const mq = window.matchMedia('(prefers-reduced-motion: reduce)'); if (mq.matches) { document.querySelectorAll('img[data-animated]').forEach(img => { img.src = img.dataset.staticSrc; }); }

另外还有一条基本要求：动图必须有替代文本。alt里写清楚这张图在表达什么，因为对读屏软件用户来说，动图就是一段无法读取的信息，alt是唯一的补偿。别写"示意图""动图"这种废话，写"三步完成配置：打开设置、选择模板、点击导出"。

6. 一条能批量跑的产出流水线

6.1 素材准备阶段的三个硬规矩

出图质量的上限在素材阶段就定了，编码只能往下拉，不能往上抬。所以进流水线之前先把这三件事做掉：

规矩一：帧序列统一为 PNG 或高质量位图，不要从已经压过的素材二次转。拿一个已经带压缩伪影的视频去转 GIF，量化会把伪影进一步放大，结果就是满屏色块。如果源是视频，解码时用高质量参数导 PNG 序列。

规矩二：帧率在导出序列时就定好，不要后期抽帧。后期抽帧容易抽到运动模糊的中间帧，看起来一顿一顿的。直接从源按目标帧率重采样，运动更连贯。

规矩三：背景先合成掉。前面讲过，半透明像素是灰边的元凶。在导 PNG 序列之前就把背景铺好，输出不带 alpha 的序列图，后面省一堆事。

6.2 两遍法：先统计调色板，再映射

这是保证整段动画色调一致的关键。第一遍扫所有帧，统计颜色分布生成全局调色板；第二遍用这套板子去映射每一帧。命令结构大概是这样：

# 第一遍：统计所有帧的颜色分布，生成全局调色板 # stats_mode=diff 表示只统计帧间变化的区域，避免静态背景主导调色板 ffmpeg -i frames/%04d.png \ -vf "palettegen=stats_mode=diff:max_colors=128:reserve_transparent=0" \ -y palette.png # 第二遍：用这套调色板映射每一帧，输出动图 ffmpeg -i frames/%04d.png -i palette.png \ -lavfi "paletteuse=dither=bayer:bayer_scale=3:diff_mode=rectangle" \ -loop 0 -y output.gif

几个参数值得单独解释：

• stats_mode=diff：只统计变化区域。对录屏类素材效果非常明显，否则调色板会被大片不变的桌面背景吃掉大半颜色预算。
• max_colors=128：颜色预算。别迷信 256，很多时候 128 甚至 96 肉眼分辨不出来。
• dither=bayer:bayer_scale=3：有序抖动，强度 3。数值越小网点越密、越平滑、体积越大；5 以上基本只剩颗粒感。要完全关闭就写dither=none。
• diff_mode=rectangle：开启矩形差分帧，只编码变化区域。对局部更新的动效收益巨大。
• -loop 0：无限循环。填 1 表示播一遍，填 N 表示播 N+1 遍（这个语义容易搞错，实测确认过）。

6.3 帧间优化的二次加工

第一遍出来的动图通常还有 20% 到 40% 的压缩空间可以榨。用帧间优化工具再过一遍，它会把完全相同的连续帧合并、把不变区域改成透明、重新计算差分矩形。常用的参数组合：

# -O3 最高级别帧间优化；--lossy 有损强度，先不带，看体积决定 gifsicle -O3 --careful input.gif -o step1.gif # 若体积仍超标，叠加低强度有损，注意检查文字和运动边缘 gifsicle -O3 --lossy=30 --careful step1.gif -o step2.gif # 需要精确控制尺寸时再缩放，用高质量重采样 gifsicle --resize-width 720 --scale-method=lanczos3 step2.gif -o final.gif

--careful这个参数很多人不知道，它的作用是避免优化过程中产生视觉瑕疵，代价是压缩率略低一点。对于有文字、有细线的素材，强烈建议加上，因为默认优化在某些边界情况下会把细线"优化"没。

一个实测经验：-O3对录屏类素材通常能再省 25% 到 45%，对实拍素材只能省 5% 到 15%。如果你的素材是实拍的，别在这上面浪费时间，回去砍尺寸更划算。

6.4 交付前的自检清单

我每次出图都会跑一遍这个清单，五分钟能省掉后面几小时的返工：

1. 总时长对不对：把每帧延迟加起来，跟目标时长比对，误差超过 3% 就回去调延迟表。
2. 有没有 0 或 1 的延迟值：有就改，不然在某些浏览器上会慢十倍。
3. 第一帧是不是最佳封面：单独导出第一帧看，能不能一眼说明问题。
4. 放到深色和浅色两种背景上看一遍：检查透明边缘有没有灰边、有没有漏透明。
5. 在目标尺寸下看文字：缩放到实际展示尺寸（比如页面里只有 480 宽），看关键文字还能不能读。
6. 循环衔接是否突兀：把最后一帧和第一帧拼起来看，接缝明显的话调整首尾帧。
7. 文件体积是否在预算内：给个参考，页面内嵌的演示动图控制在 500KB 以内比较安全，超过 1MB 就要考虑换格式或拆段。

这里第 6 点值得多说一句。循环动图的首尾衔接是个高频问题——录屏截取的时候随便切一刀，播放时就会看到画面"跳"一下。解决办法有两个：一是首尾各留一段静止画面，让接缝落在静止处；二是做首尾帧融合，把第一帧和最后一帧按 50% 混合生成一个过渡帧插在末尾，视觉上就顺了。后者会多一帧，但衔接质量提升明显，我基本都这么做。

动手做动图这些年，最深的体会是：大部分"GIF 画质差"的抱怨，其实是选错了工具。该用视频的地方硬上 GIF，怎么调都是徒劳。反过来，只要素材合适（纯色、扁平、区域更新为主），把帧延迟表算准、调色板统计对、抖动按需开，256 色做出来的动图完全可以又清晰又小。另外分享一个小技巧：批量处理之前，先拿最有代表性的 3 秒素材做全参数矩阵测试，把尺寸、帧率、颜色数、抖动的几个组合都跑一遍，记下体积和观感评分，选出两三个候选配置再套到全量上。这个前置测试花二十分钟，能避免几百张图重做的灾难。