它要的不是壓得最小，是快得離譜

壓縮這件事通常有個取捨：輸出越小，做的工越多。Google 以 BSD 風格授權開源的 Snappy 故意走反方向。它不追最高的壓縮率，追的是一個幾乎不講理的速度：在普通桌上型處理器的單一核心上，壓縮可以做到每秒 250MB 以上，解壓超過每秒 500MB，比傳統壓縮函式庫最快的模式還快上一個數量級，代價是壓完之後體積大兩成到一倍。這個取捨讓它在「壓縮不能拖慢業務」的場合特別好用：資料庫儲存、大數據系統、日誌管道，還有很多知名分散式系統底層的壓縮層。2026 年 9 月為止的版本是 1.2.2。

速度是從哪裡來的

這份快不是手寫組譯的魔法變出來的，而是兩層取捨的結果：一層在演算法，一層在工程。壓縮策略簡單直接，只在鄰近的資料裡找重複片段，省掉複雜建模的運算開銷；實作則針對主流 64 位元處理器深度最佳化，一次處理更多資料。完全不寫組譯也能跑到高吞吐，順帶把可攜性與可維護性都保住了，跨平台的表現因此穩定。專案附了基準測試工具，接進自家專案之前先拿自己的資料跑一輪，就能知道會拿到什麼樣的速度與壓縮比。

在生產環境裡磨出來的穩定

可靠度背後有真實的履歷：多年來它在 Google 內部處理過 PB 等級的資料壓縮，位元流格式一直保持穩定，跨版本相容這件事使用者不必擔心被打破。解壓端是仔細設計過的，就算喂進損壞、甚至刻意構造的惡意輸入也不會垮，這對處理不可信資料的服務尤其重要。函式庫以 BSD 風格授權開源，商用沒有負擔；以 C++ 撰寫並提供 C 介面，各語言都有成熟的第三方繫結，接進自家專案並不困難。

誰在用，為什麼是它

不少主流資料庫與大數據元件的預設或可選壓縮選項裡都有它的身影：列式儲存引擎用它壓資料區塊，訊息系統用它壓網路傳輸，嵌入式儲存用它壓落盤的檔案。這些系統的共同點是讀寫頻繁、對延遲敏感，壓縮多花一毫秒都會被放大成效能問題，正是這種「既要壓、又要快」的需求塑造了它的設計哲學。對個人開發者來說，要替自己的儲存專案、日誌工具或網路協定加一層壓縮，它也是上手成本低、說明清楚的選擇，原始碼與格式說明都公開。

什麼時候該用它，什麼時候不該

判斷標準很簡單：資料量大、對吞吐敏感、儲存成本可以接受時，它是最好的答案之一，典型壓縮比大約文字 1.5 到 1.7 倍、網頁類內容 2 到 4 倍；本來就已經壓過的圖片與影片，它不會再處理一次。反過來說，若目標是越小越好，例如歸檔保存、或頻寬很貴的場合，就該挑壓縮率更高的演算法。建置依賴簡單，標準工具鏈就夠；專案同時附了基準測試與正確性測試工具，調校與驗證都方便。對需要自研儲存與傳輸鏈路的團隊，這個小而硬派的函式庫值得收著。