做一个 GIF 只有三个决定：里面放什么、放多快、给多少颜色。剩下的都是细节。这篇把三件事连同真正重要的数字讲一遍，全程用浏览器里的编辑器完成，所以过程中什么都不会被上传。
2026 年 9 月 12 日 · 约 7 分钟
导入任何东西之前，先想清楚这个 GIF 要去哪里。放进 README、当 Slack 表情、塞进邮件周报、发到社交平台，这几件事的体积预算和合理尺寸各不相同，而后面每一个决定都由它推导而来。
最先要定下来的两个数字是宽度和时长。宽度决定像素总量，它对体积的影响超过任何编码器参数；时长决定帧数，影响力几乎同样大。480px 宽、4 秒，对大多数去处都是个舒服的目标。800px、10 秒则不是，而且怎么调参数都救不回来。
| 去处 | 宽度 | 时长 | 预算 |
|---|---|---|---|
| README / 文档 | 600–800 px | 5–15 秒 | 5MB 以内 |
| Slack、Discord | 400–600 px | 2–6 秒 | 2MB 以内 |
| 邮件周报 | 480–600 px | 2–4 秒 | 1MB 以内 |
| 社交平台 | 480–640 px | 2–6 秒 | 15MB 以内 |
邮件是最紧的那个。很多客户端只显示第一帧，所以把信息放进第一帧，把动画当成附赠。
有两条路。从视频来：导入片段，裁到你要的那一段，然后选一个采样频率——编辑器会跳到均匀分布的时间点上逐个抓取。从图片来：把文件拖进去，每张变成一帧，想让它停多久都行。
先裁剪，什么都排在它后面。只有你保留的范围会被抽帧，所以从十分钟录像里截六秒，做的是六秒的工作而不是十分钟的。这同时也是你能为文件体积做的最大一件事，而且完全不损失画质。
GIF 没有帧率字段。每一帧自带一个以百分之一秒为单位的延时，播放器就是等这么久再往下走。一个让你填 "FPS" 的工具，是在把同一个延时写进每一帧。
正因为要取整到百分秒，30fps 其实拿不到：三十分之一秒等于 3.33 个百分秒，只能变成 3（约 33fps）或 4（25fps）。选一个能整除的帧率，播放效果才会和预览一致。
GIF 的一帧最多 256 色，取自一套要么覆盖整个文件、要么逐帧重建的调色板。颜色越少文件越小，少过某个点之后会出现可见的断层。
有用的习惯是从 256 往下一档档试，停在你第一次看出差别的地方。扁平素材——录屏、插画、任何有大片同色区域的东西——常常在 32 色下毫发无损。照片类素材通常需要 128 色，再配上抖动把剩下的过渡抹匀。
抖动可能让文件变大。它把平坦、极易压缩的区域换成细密噪点，用字节买来更平滑的渐变。扁平图形上，直接关掉。
大多数工具要你导出之后才知道结果多大，于是调参变成了每次尝试都夹着一次下载的猜谜。而一个真的编码几帧样本、再按整条时间轴外推出来的预估，能把这个循环整个去掉。
数字摆在眼前之后，操作顺序就变得显而易见：缩画布、砍帧数、再减颜色，每一步之后看一眼。通常前两步就够了，第三步根本用不上。
GIF 是 1987 年的格式，封顶 256 色，帧与帧之间没有运动补偿。一段五秒的视频做成 GIF 有 3MB，做成 MP4 或 WebM 常常不到 300KB，画质还更好。
如果目标平台收视频——Slack、Discord、大多数文档工具和所有社交平台现在都收——那么改导 MP4 是一个调参永远达不到的十倍级改善。把 GIF 留给真正需要它的地方：邮件客户端、老旧 wiki，以及任何"没有播放器也要内联循环播放"的场合。