JSON 壓縮

只刪除空白

JSON 語法允許在任意兩個詞法單元之間放置空格、製表符和換行，而這些字元都不攜帶任何含義。所謂壓縮，就是把這些可選字元全部去掉：{"a": 1, "b": 2} 變成 {"a":1,"b":2}。解析後的值在記憶體中完全一致，因此在傳送資料前做這一步永遠是安全的。

壓縮不做的事情是「壓縮資料」。鍵名、字串內容和數字精度都被原樣保留。如果你的文件很大是因為在一萬條記錄裡重複了同樣的二十個欄位名，壓縮只能省掉縮排，重複本身依然存在——那是 gzip 或者換一套資料結構才能解決的問題。

什麼時候這點節省才真的有意義

一份典型的格式化 API 響應中，空白大約佔原始體積的 10% 到 30%。這聽上去很可觀，但別忘了幾乎所有 HTTP 響應在傳輸時都已經過 gzip 或 brotli 壓縮，而壓縮演算法處理連續空格的效率極高。經過 gzip 之後，壓縮版與格式化版 JSON 的差距往往不到 2%。

壓縮仍然在三種場景裡站得住腳：直接內聯進 HTML 頁面或 JavaScript 包的資料，因為它們不會被單獨壓縮；存進資料庫欄位或快取的資料，因為佔空間的正是原始字串；以及任何需要與硬性長度上限較勁的地方，例如 URL 引數或有固定長度限制的訊息欄位。

用鍵名排序做對比

JSON 物件在規範上是無序的，但每個序列化實現都會按某個具體順序寫出鍵名，而兩套系統很少會選一樣的順序。於是兩份邏輯完全相同的文件做純文本 diff 時會一片紅。

在輸出前遞迴地對鍵名排序，能讓兩份文件得到相同的規範形態，行級 diff 這才只顯示真正的差異。可復現構建和內容定址快取背後用的也是同一招。但要記住：排序會改變輸出的位元組內容，排序後的文件不再與源系統產出的完全一致——它適合用來對比，不適合用來回傳需要校驗簽名的資料。