Go生成GIF的关键在于帧时序控制、调色板复用和内存管理；需用*image.Paletted统一调色板、正确设置Delay（单位10ms）、避免alpha通道，并优先缩放尺寸以控体积。
Go 生成 GIF 动图本身不难，但「动起来」的关键不在 image/gif 包本身，而在于帧序列的时序控制、调色板复用和内存管理——多数卡顿或体积爆炸都源于这里。
如何用 gif.EncodeAll 正确写入多帧
直接调用 gif.EncodeAll 是最简方式，但它要求你提前准备好所有帧（[]*image.Paletted）和对应延时（[]int）。它不支持流式写入，所有帧必须驻留内存。
常见错误是传入空 Delay 或全 0 延时，导致浏览器/查看器默认用 100ms 甚至直接静止。GIF 规范中延时单位是 10ms，所以 10 表示 100ms。
- 每帧必须是
*image.Paletted类型，普通*image.RGBA会 panic - 所有帧应共用同一调色板（
palette.Plan9或自定义），否则编码器会为每帧重算调色板，体积暴增、颜色失真 - 延时数组长度必须等于帧数，少一个就 panic，多一个被忽略
g := &gif.GIF{
Image: frames, // []*image.Paletted
Delay: delays, // []int，如 []int{10, 10, 10}
LoopCount: 0, // 0 = 无限循环
}
gif.EncodeAll(w, g)
为什么用 gif.Encode 逐帧写更可控
当帧数多、内存敏感（比如服务端批量生成）或需动态控制帧间逻辑（如跳过空白帧、按 CPU 负载限速），应改用 gif.Encode 配合手动写入。它允许边生成边写，避免全帧驻留。
立即学习“go语言免费学习笔记（深入）”；
关键点：每次调用前必须重置 image.Paletted 的矩形区域（bounds），否则后续帧会叠加在前一帧上（表现为残影）；且每帧的 Dispose 字段要设对（通常用 gif.DisposalBackground 清除上一帧）。
- 务必在每次
gif.Encode前调用paletted.ReplacePalette(p)复用同一调色板 - 若源图是
*image.RGBA，用color.NRGBAModel.Convert转换后再量化，别直接强制类型转换 - 写入前清空
paletted.Rect.Min到Max区域，否则旧像素残留
常见报错：invalid image: bounds do not match palette
这个错误几乎只发生在你把非 Paletted 图像（比如 *image.RGBA）直接塞进 gif.Encode，或调色板尺寸与图像实际颜色数不匹配时。
GIF 最多支持 256 色，但 Go 的 image.Paletted 不会自动帮你降色——你得先用 quantizer（如 golang.org/x/image/draw 里的 Quantizer）或手动采样。别依赖 image/color.Palette 的 Convert 方法，它不保证颜色数 ≤256。
- 安全做法：用
paletted := image.NewPaletted(bounds, palette)显式创建，再用draw.Draw把源图绘制进去 - 调试时打印
len(paletted.Palette)，确保 ≤256 - 如果源图含 alpha，GIF 不支持半透明，需预乘或丢弃 alpha 通道
生成慢 / 体积大？先查这三处
生成耗时长、输出文件远大于预期，问题往往不在编码逻辑，而在前置处理：
- 没做尺寸缩放：原始 1920×1080 图转 GIF，哪怕只有 10 帧也极易超 5MB。用
draw.ApproxBiLinear缩到 400px 宽以内再处理 - 调色板未复用：每帧独立调色板会让文件体积翻倍甚至十倍，且动画闪烁
- 延时设太高或太低：低于
2（20ms）多数设备无法稳定播放；高于100（1s）看起来就是幻灯片
真正难的不是“怎么生成”，而是“怎么让生成结果在不同设备上都流畅、小、颜色准”——调色板管理、帧间差异压缩、alpha 处理，这些细节没绕过去，就只是能跑，不是能用。
