第一次把一段 10 秒的视频转成 GIF，很多人会被结果吓一跳：源视频 2MB，转出来的 GIF 25MB。
这不是工具的问题，是 GIF 这个 1987 年的格式本身的限制。理解了限制在哪，就知道该拧哪个旋钮。
一、GIF 为什么这么大
两个硬伤：
只有 256 色。 GIF 每帧最多用一个 256 色的色板。真彩色视频有 1600 万色，压进 256 色必然要做色彩量化——所以渐变会出现色带、肤色会脏。为了缓解，编码器会做抖动（dithering），而抖动引入的噪点又会让压缩效率进一步下降。
几乎不做帧间压缩。 现代视频编码（H.264 等）的核心优势是只记录「这一帧和上一帧的差异」，静态背景几乎不占空间。GIF 的帧间优化能力很弱，基本是一帧一张图地存。这就是为什么GIF 体积几乎和帧数成正比。
结论：GIF 的体积主要由 帧数 × 每帧像素数 决定，而帧数 = 帧率 × 时长。
二、三个旋钮的收益排序
按「减体积效果」从大到小：
1. 缩短时长。 收益线性且立竿见影。表情包类的 GIF 控制在 2–4 秒，说明演示类控制在 8 秒以内。超过 10 秒就该考虑换成视频了。先剪辑再转换，顺序反了会白等一遍。
2. 降帧率。 这是最容易被忽略的一个。参考值：
- 10 fps：表情包、简单动作，完全够用，观感也自然
- 15 fps：日常推荐，动作流畅度和体积的平衡点
- 24 fps 以上：只在快速运动画面才需要，体积会翻倍
从 24 fps 降到 12 fps，帧数直接砍半，体积基本也砍半。
3. 缩小尺寸。 体积随面积变化，长边从 640 缩到 480，面积只剩 56%。表情包类 长边 300–480 像素就够了，微信里显示区域本来就不大。
三、一个实操配方
「把手机录的 15 秒视频做成能发微信的表情包」：
- 先剪，只留最精彩的 3 秒
- 尺寸：长边 360
- 帧率：12 fps
- 转换后看结果，通常在 1–3MB
如果还是太大，优先继续降帧率到 10，其次把长边压到 300，最后才考虑再剪短。
四、什么时候不该用 GIF
这一条比参数更重要：
- 需要声音 → GIF 不支持音频，必须用视频
- 超过 10 秒 → 用 MP4，体积小一个量级且画质好得多
- 画面色彩丰富（风景、人脸特写、渐变） → GIF 的 256 色会明显毁掉画质
- 只是要在自己网页上放个循环动画 → 用
<video>标签配 MP4/WebM，自动播放+静音+循环，体积可能只有 GIF 的十分之一
GIF 真正无可替代的场景其实很窄：需要在不支持视频标签的地方（比如某些 IM、论坛、邮件客户端）里自动播放的短动画。
五、两个工具的分工
视频转 GIF：源是视频文件，走 ffmpeg.wasm 解码后逐帧生成。需要先下载约 30MB 的 wasm 内核（同一次访问只下一次），处理速度取决于本机 CPU。
GIF 制作：源是多张图片，把它们按顺序合成动画。适合做逐帧手绘、图表演示、多张截图连播。不需要视频解码，更快。
两者的输出都在你的设备上生成，文件不会上传服务器。
常见问题
转出来颜色发灰、有色带？ 256 色限制导致的量化损失，无法根治。减轻办法：降低画面复杂度（裁掉杂乱背景）、避免大面积渐变。
GIF 能循环几次？ 默认无限循环。也可以设定固定次数，播完停在最后一帧。
微信对 GIF 有大小限制吗？ 作为表情发送有明确上限（通常在几 MB 量级，具体值随版本变化），超了会被压缩或拒绝。控制在 2MB 以内比较稳。
为什么进度走得很慢？ 逐帧解码 + 色彩量化都发生在你的浏览器里，帧数越多越慢。降帧率能同时减小体积和缩短处理时间。
能转成 WebP 动图吗？ 同画质下动态 WebP 比 GIF 小很多，但兼容性不如 GIF——很多 IM 和老软件不认。发给别人还是 GIF 稳。