錄了一段 5 秒的操作演示，導出成 GIF，一看大小：18 MB。
想貼進文件、發到群裡、放進 README，不是上傳失敗，就是加載半天轉圈。
一張「動圖」憑什麼比一段視頻還大？又該怎麼把它壓小，還不讓它變得滿屏噪點？
先搞清楚：GIF 為什麼這麼大
GIF 是 1987 年的格式，它的幾個先天設定決定了它「胖」：
- 每一幀都是一張完整的圖片。沒有視頻那種「只記錄變化」的幀間壓縮——除非導出時專門做了優化，否則 100 幀就是 100 張圖。
- 壓縮算法很老。GIF 只用 LZW 無損壓縮，擅長的是「連續一樣的顏色」，遇到漸變、照片、細碎紋理就幾乎壓不動。
- 每幀最多 256 色。顏色不夠，導出工具就用「抖動」（dithering）——用密密麻麻的雜色點模擬過渡。這些噪點肉眼看是平滑的，對 LZW 來說卻是最難壓的數據。
所以一張 GIF 的體積，大致取決於：尺寸 × 幀數 × 每幀畫面有多「碎」。下面所有辦法，都是對在這三項下手。
六種辦法，按畫質損失從小到大
1. 幀優化：只存「變了的那塊」（無損）
很多錄屏工具、設計軟件導出的 GIF，每幀都存了整張畫面。但一段操作演示裡，往往只有鼠標和一小塊區域在動。
幀優化做的事是：每一幀只保留和上一幀不同的矩形區域，沒變的部分用透明像素表示。透明像素連成一片，LZW 壓起來非常高效。
畫面一個像素都不變，動畫效果完全一樣，只是存儲方式更聰明。對「背景不動、局部在動」的 GIF（錄屏、UI 演示、表情包），這一步就能省下不少。
2. 有損 LZW：在壓縮算法裡「放一點水」（視覺無損）
這是 gifsicle 的 --lossy 參數帶來的思路：編碼時允許顏色有極小的偏差，讓更多像素被當作「同一種顏色」連起來，LZW 的效率就大幅提高。
它的特點是：不減少顏色數、不改尺寸、不動幀，代價是畫面裡出現一點輕微的顆粒感。數值越大，省得越多，顆粒越明顯。輕度使用時（比如 --lossy=30~40），在正常觀看距離下很難察覺。
3. 減色：256 色降到 128 或 64
把調色板從 256 色減到 128 色甚至 64 色，每個像素需要的信息變少，壓縮效率隨之提升。
對扁平風格的插畫、圖標動畫、UI 錄屏，顏色本來就不多，減色幾乎沒有損失；但對照片類、漸變多的畫面，減色會出現明顯的色帶和斑塊。
4. 抽幀：降低幀率
很多 GIF 是按 30 fps 甚至 60 fps 導出的，但 GIF 本身並不擅長高幀率，很多場景 10~15 fps 已經夠用。
幀數砍一半，體積通常也接近砍一半。代價是動作沒那麼順滑——對操作演示影響不大，對需要流暢感的動畫就比較明顯。
5. 縮小尺寸
體積和像素數基本成正比：寬高各縮一半，像素數只剩四分之一。
在 Retina 屏上錄的屏，原始寬度動輒 2000 多像素，而它最終往往只顯示在 600~800 像素寬的位置。按實際顯示尺寸導出，常常是收益最大的一步。代價是放大看會變糊，文字類內容要留意可讀性。
6. 換格式：GIF 換成視頻或 WebP
如果平台允許，最徹底的辦法是不用 GIF：
- MP4 / WebM：現代視頻編碼有幀間壓縮，同樣的內容，體積往往只有 GIF 的幾分之一。網頁裡用
<video autoplay loop muted playsinline>就能做出和 GIF 一樣的效果。 - 動態 WebP / APNG：支持更多顏色和更好的壓縮，現代瀏覽器都能播放。
代價是兼容性：不少聊天軟件、論壇、文件工具、郵件客戶端只認 GIF，換了格式可能直接顯示不出來，或者不會自動播放。
一張表看清取捨
| 辦法 | 畫質影響 | 適合 | 不適合 |
|---|---|---|---|
| 幀優化 | 無，像素不變 | 所有 GIF，尤其錄屏和局部動畫 | ——（應該總是做） |
| 有損 LZW（輕度） | 極輕微顆粒 | 絕大多數 GIF | 對顆粒極敏感的像素畫 |
| 減色 | 漸變處出現色帶 | 扁平插畫、圖標、UI | 照片、漸變多的畫面 |
| 抽幀 | 動作變卡 | 操作演示、靜態居多的動畫 | 需要流暢感的動畫 |
| 縮小尺寸 | 細節變少 | 原圖明顯大於顯示尺寸 | 需要看清小字的內容 |
| 換格式 | 通常更好 | 網頁、自己能控制的平台 | 只認 GIF 的平台 |
順序的邏輯是：先做不損失或幾乎不損失的，再按需要往下走。前兩步做完如果已經夠小，就不必犧牲顏色、幀率和尺寸。
前兩步，ImgZilla 可以替你批量做完
如果你手裡是一堆 GIF——表情包收藏、文件裡的演示動圖、網站素材目錄——一張張丟進在線工具調參數實在太累。
ImgZilla 是一款 macOS 圖片壓縮工具，處理 GIF 時用的正是上面表格的前兩項：
- 基於 gifsicle：先做最高級別的幀優化（相當於
-O3），再疊加輕度有損 LZW（相當於--lossy=40）。 - 不減色、不抽幀、不改尺寸、不改循環設置。動畫還是原來那個動畫，幀率、時長、分辨率都不變，只是文件更小。
- 原地壓縮：文件名、路徑、格式都不變。文件、網頁、Markdown 裡引用的
demo.gif壓完還是demo.gif，不用改任何鏈接。 - 整個文件夾拖進去即可：遞歸掃描子目錄，GIF 和 JPG、PNG、WebP 等其他圖片一起處理。
- 壓不動的不硬壓：已經被優化過、壓縮率不足 0.4% 的文件會標為「已最小」，原樣保留，也不扣免費額度。
- 原圖默認移入廢紙簍：覺得哪張效果不滿意，右鍵「放回原處」即可還原。
- 全程本地運行，不上傳任何服務器，也沒有在線工具那種單張大小和張數的限制——幾十 MB 的錄屏 GIF 也照樣處理。
能省多少，取決於 GIF 原來是怎麼導出的。沒做過幀優化、畫面大部分靜止的錄屏 GIF，通常省得最多；已經被專業工具壓過的 GIF，可能只剩一點餘量，甚至直接被標為「已最小」——這都是正常的。
ImgZilla 不做的事
為了「動畫看起來不變」，ImgZilla 不會替你做第 3~6 步。如果前兩步壓完還是太大，比如必須壓到某個平台的上限以內，就需要你自己決定犧牲什麼：
bash
用 gifsicle 命令行：減到 128 色、寬度縮到 640、更強的有損壓縮
gifsicle -O3 --lossy=80 --colors 128 --resize-width 640 input.gif -o output.gif
用 ffmpeg 把 GIF 轉成 MP4（體積通常小得多）
ffmpeg -i input.gif -movflags +faststart -pix_fmt yuv420p
-vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" output.mp4
抽幀、裁剪時長這類需要逐幀挑選的操作，用 ezgif 這類在線編輯器會更直觀。
一個更好的習慣：在源頭就別導出太大的 GIF
最後三條建議，能讓你以後少壓很多次：
- 錄屏前先縮小窗口，只錄需要的區域，而不是整塊 Retina 屏幕。
- 導出時選 10~15 fps，大多數演示已經足夠。
- 導出後順手壓一遍，把幀優化和輕度有損做掉——這一步不需要任何判斷，適合交給工具批量完成。
GIF 是個老格式，但它依然是「到處都能自動播放」的最大公約數。與其糾結要不要放棄它，不如讓每一張 GIF 都只占它該占的空間。
ImgZilla 目前僅支持 macOS（12.3 及以上），可在 Mac App Store 下載。免費版每天可壓縮 10 張，只有壓縮成功才計入額度——把存滿 GIF 的文件夾拖進去，看看能省下多少。