在严格约束里保持创意自由：给 Slack 做动图的工程思路

做工具库的时候有一种常见的错误倾向：把约束和创意自由当成对立面，要么做成"什么都能改的配置大全"，要么做成"按菜单点的固定模板"。这两种极端都很难用。前者把复杂度甩给调用者，后者让人感觉被框死。

给 Slack 制作动画 GIF 这个需求，把这个矛盾推到了极端——Slack emoji GIF 的文件大小上限是 64KB，这个数字严苛到你随手截一张 128×128 的截图都不一定塞得进去。如何在这个硬约束下，同时让动画制作保留足够的创意弹性？这是让我觉得值得聊一聊的设计问题。

两种 GIF，两套规格

Slack 的 GIF 分两类，约束差距悬殊：

• 消息 GIF：上限约 2MB，480×480，15-20 fps，颜色 128-256 色
• emoji GIF：上限 64KB，128×128，10-12 fps，颜色最多 48 色

消息 GIF 几乎没有障碍，按正常流程做就行。emoji GIF 是真正的工程挑战：10-15 帧、32-48 色，这意味着你必须在设计阶段就做出取舍——没有渐变、没有复杂背景、动画要简洁。

面对这种约束，常见的错误做法是"先做好再压缩"——结果每次都超，每次都靠削减帧数和色彩数来勉强达标，最终效果比一开始就按约束设计要差很多。正确的做法是把约束前置到设计决策里，而不是后置到优化步骤里。

组合式原语，而不是固定模板

这个工具库的核心思路是把常见动效抽成独立的「动画原语」——抖动（shake）、弹跳（bounce）、旋转（spin）、脉冲（pulse）、淡入淡出（fade）、缩放（zoom）、滑动（slide）……每一种都是可以独立调用、也可以组合叠加的构建块。

这个设计选择背后的逻辑是：动画的创意空间来自组合，而不是单个效果的参数多样性。一个球落地的动画，单独用 bounce 可以做，但加上落地瞬间的 shake + 闪光效果，整个动画的冲击感就完全不一样了。如果把这两个效果做成一个大模板，就失去了单独使用或者与其他效果组合的灵活性。

# 落地后叠加抖动：bounce 原语 + 自定义震动逻辑
for i in range(num_frames):
    t = i / (num_frames - 1)
    y = interpolate(start_y, ground_y, t, 'bounce_out')
 
    # 落地瞬间加入水平抖动
    if y >= ground_y - 5:
        shake_x = math.sin(i * 2) * 10
        x = center_x + shake_x
    else:
        x = center_x

关键在于 easing 函数的设计——ease_in、bounce_out、elastic_out、back_out 这些缓动曲线让运动有了物理感，而不是机械的线性插值。这一层抽象非常值得投入，它直接决定动画「有没有生命力」。

校验器作为设计伙伴

文件大小校验不应该只是发布前的最后一道关卡，它应该是整个制作过程的伴随者。工具库提供了几个轻量的校验函数：

from core.validators import check_slack_size, is_slack_ready
 
passes, info = check_slack_size('emoji.gif', is_emoji=True)
# info 包含 size_kb、frame_count、duration_seconds 等
 
if is_slack_ready('emoji.gif', is_emoji=True):
    print("可以上传了")

这些函数设计得刻意轻量——不抛异常、不阻断流程，只是返回布尔值和详情字典。这样可以在制作中途随时调用，而不是等到最后才发现超标再回头大改。

优化是有顺序的

当 GIF 确实超标时，优化应该按影响范围从小到大依次尝试：

1. 先减颜色（128 → 64 → 32），视觉损失最小
2. 再减帧数（降低 fps 或截短动画），影响流畅度
3. 最后缩小尺寸，影响清晰度

很多人习惯反过来——先缩尺寸，结果图变糊了，文件还是超标。颜色数量对文件大小的影响远比尺寸大，因为 GIF 格式本身是基于调色板压缩的，颜色越少、重复块越多，压缩率越高。

一句话心法

工具库的职责是在技术约束内最大化创意自由度——把约束封装进校验器，把自由度放进可组合的原语，不要把两者混在一个大模板里。