同一段 60 帧的动画，在同一个页面里换参数重编，最小的 GIF 是 11372 字节，最大的是 95206 字节。

差了 8.4 倍。两者内容一模一样，只有输出宽度、帧率、颜色数和抖动开关不同。

我把整条链路做成了一个能点开的网页：GIF89a 编码、中位切分调色板、LZW 压缩、Floyd-Steinberg 抖动全部自己实现，10 组参数一键对照，跑完直接给体积、耗时和 PSNR。

一、为什么值得看：GIF 的体积是几个参数乘出来的

GIF 的压缩能力其实很弱。

它只有一张最多 256 色的调色板，每个像素只存调色板下标，再叠一层 LZW 无损压缩。

所以体积基本由三件事决定：像素总量（宽 × 高 × 帧数）、颜色数、画面里有没有高频细节。

我拿同一段示例动画把这三件事各推了一遍。

颜色数从 16 加到 256，体积从 31461 字节涨到 90079 字节，2.9 倍。

帧率从 10 提到 20，同尺寸下从 16761 字节涨到 90079 字节，5.4 倍。

宽度从 128 换成 256，像素数翻 4 倍，16 色那组从 11372 字节到 31461 字节。

三个参数乘在一起，8.4 倍的落差就出来了。

顺带说一个反直觉的点：加抖动会把体积顶上去，同一组参数下 90079 字节变 95206 字节，涨了 5.7%。

抖动不省体积，它是拿体积换视觉上的平滑。

二、准备环境：打开码道 Web 就能用

码道有三种使用方式：WebUI（浏览器对话）、TUI（终端命令行）和桌面 IDE（IDE 插件）。本文用 WebUI 版演示。

浏览器打开码道 Web 版：devcloud.cn-north-4.huaweicloud.com/chat?source…

登录之后直接在对话窗口里说需求，不需要装任何软件。

三、任务描述：把这段需求原文丢给码道

下面是我实际发给码道的那段话，一字未改，复制过去就能复现同一个应用。

用 HTML 做一个单文件网页应用：GIF 压缩实验室（界面全中文）。


硬性要求：
1) 单个 index.html，纯原生 JS，不引用任何外部 CDN 或第三方库，离线也能跑。
2) 内置一段示例动画（用 canvas 程序生成，约 60 帧，例如来回弹跳的小球 + 旋转方块 + 背景网格），打开就能用，不依赖用户上传文件。
3) 也支持用户上传多张图片或一段视频，自动采样成帧序列。
4) 在浏览器里用纯 JS 自己实现 GIF89a 编码器：中位切分(median-cut)调色板量化 + LZW 压缩 + 可选 Floyd-Steinberg 抖动。可调参数：输出宽度、帧率(抽帧)、颜色数(2/4/8/16/32/64/128/256)、抖动开关、循环次数。
5) 生成后在页面里直接播放这个 GIF，并给出下载链接；同时显示：原始帧数/尺寸、输出 GIF 字节数、输出帧数、实际颜色数、编码耗时、压缩比。
6) 一个参数对照面板：一键跑 10 组参数组合（尺寸 x 帧率 x 颜色数 x 抖动），列出每组的体积、耗时、平均色差(或 PSNR)，并高亮体积最小的一组。
7) 页内自检 12 项并显示通过/失败，例如：GIF 文件头是 GIF89a、结尾是 0x3B、量化后实际用到的颜色数不超过设定值、开启抖动后平均色差下降、颜色数越大体积单调不减、输出帧数等于期望帧数、把生成的 GIF 数据重新用浏览器解码回读并与源帧比对误差在阈值内。
8) 参数非法时给中文提示：颜色数必须是 2~256 的 2 的幂、宽度必须大于 0、帧率必须大于 0、没有帧数据等。
9) 界面排版要大屏友好，窗口最大化时不空。


完成后打开预览，让我直接看到运行效果。

python -m http.server 8080
# 浏览器打开 http://localhost:8080/index.html

我自己的验收动作是三步：先看默认结果是不是 88.0 KB 左右的 GIF、能不能在页面里动起来；再把颜色数从 256 调到 32、打开抖动，看体积和 PSNR 是不是按上表那样变化；最后把宽度清成 0，确认提示是「宽度必须大于 0」而且不清空上一次的结果。

八、使用码道体会

• 验收标准要写死在提示词里。 我写了「生成后在页面里直接播放这个 GIF」「把生成的 GIF 数据重新用浏览器解码回读并与源帧比对误差在阈值内」，它就把自检做进了页面。不写，多半只会给你一个下载按钮。

• 让页面自己报数。 体积、耗时、PSNR、色差这四列不是我算的，是页面跑出来的，我只是抄下来。读者能点开同一个页面复现同一批数字，可信度完全不一样。

• 要求「对照面板」而不是「说明一下」。 一开始我以为 10 组对照只是个好看的面板，跑完才发现颜色数的边际收益在 64 色之后基本没了——这种结论只有并排跑出来才看得见。

• 自检通过不等于产品正确。 这一轮最大的教训。自检是模型自己写的，用它自己的解码器验证自己的编码器，天然会「自洽」。跨工具复核（换个标准解码器）才是真的验收。

• 报 bug 要报到行。 我把「哪一项红了、报什么错、标准解码器报什么错、根因是哪个判断早了一位」写清楚之后，它一轮就改对了；只说「GIF 打不开」，它会把解码器改坏来迁就编码器。

• 单文件交付最省事。 零依赖、零构建，file:// 能跑，发给别人不用配环境。

直接下载试玩

这个 Demo 已经完整开源（源代码、本文档、全部截图），托管在公开仓库，可直接下载来玩：

• Demo Park 仓库：atomgit.com/deli007/dem…

• 本案例目录：atomgit.com/deli007/dem…

打开上面的链接进入 codearts-gif-maker-lab 文件夹，把 index.html 下载到本地用浏览器打开即可，无需安装任何依赖。

九、总结

GIF 的体积不是玄学，是宽度、帧率、颜色数三个参数乘出来的，这段 60 帧的示例动画在 8.4 倍的范围里随便调。

调参的优先级也很直白：先砍帧率，再砍颜色数，尺寸最后动，抖动能不碰就不碰。

比参数表更值钱的，是这轮踩出来的那条规则：编码器和解码器不能互相作证；要证明一个文件是好的，得让一个跟你无关的标准解码器把它读出来。

参数在页面上，坑也在页面上。