為什麼 JSON 總是難以閱讀
每個介面回傳、每份設定檔、每行日誌都是 JSON。壓縮後它是一整塊字元牆；格式化之後同樣的資料兩秒就能掃完。資料完全相同，差的只是空白——這也是「JSON 格式化」成為開發者最常用搜尋之一的原因。
格式化、壓縮、驗證的差別
| 操作 | 改變什麼 | 什麼時候用 |
|---|---|---|
| 格式化 | 加縮排與換行 | 閱讀、審查、排查問題 |
| 壓縮 | 去掉所有多餘空白 | 傳輸、儲存設定 |
| 驗證 | 不改內容，只報語法錯誤 | 送出請求或提交設定前 |
這三件事在 JSON 格式化工具 裡都只差一次點擊，而且全程在瀏覽器本機完成。
什麼才算合法的 JSON
JSON 的語法非常小，而且比 JavaScript 嚴格得多：
- 鍵名必須用雙引號包起來
- 字串必須用雙引號，單引號不合法
- 不允許多餘的逗號
- 不允許註解（
//和/* */都不行） - 值只有這幾種：物件、陣列、字串、數字、
true、false、null - 數字不能有多餘的前導零，
NaN／Infinity也不是合法值
如果你寫過 JSON5、JSONC（VS Code 設定）或 JavaScript 物件實字，其中一些習慣在 JSON 裡是違法的。
最常踩的五個錯誤
1. 多了一個逗號
{
"name": "NavShelf",
"version": "1.0",
}
"1.0" 後面那個逗號，是 JSON 錯誤的第一大來源。
2. 用了單引號
{ 'name': 'NavShelf' }
JavaScript 合法，JSON 違法。
3. 鍵名沒加引號
{ name: "NavShelf" }
同樣：JavaScript 合法，JSON 違法。
4. 寫了註解
在設定裡加一句 // TODO，然後程式啟動失敗。標準 JSON 沒有註解語法。
5. 內容被截斷或拼接
兩個物件黏在一起，或者從日誌複製時被截斷。抓日誌時最常遇到這種。
怎麼讀懂 JSON 錯誤訊息
瀏覽器與 Node 的錯誤通常長這樣：
Unexpected token } in JSON at position 84
這裡的 position 是從字串開頭算起的字元位移，不是行號。要嘛自己數，要嘛交給工具：格式化工具 會直接告訴你 第 N 行第 M 欄，這才是修復時需要的資訊。
一套順手的流程
- 把原始內容貼進 JSON 格式化工具
- 點「驗證」，先確認能不能解析
- 點「格式化」看結構——多數時候你會發現是某個鍵寫錯或層級放錯
- 回到源頭修改，只在傳輸或儲存時點「壓縮」
- 倉庫裡存格式化版本，壓縮放到建置或傳輸環節做
關於體積
壓縮通常能省 10%～30%，取決於巢狀深度。這點節省本身意義有限，因為傳輸時的 gzip 壓縮率高得多。壓縮真正的價值在於一致性：避免因空白差異產生的合併衝突，也讓體積可預期。
常見問題
格式化會改變資料嗎？ 不會。字串之外的空白在 JSON 中是可忽略的，格式化與壓縮都是無損的。
JSON 允許重複的鍵嗎？ 規範沒有明確禁止，但行為未定義——多數解析器保留最後一個值。別這樣寫。
為什麼我的內容在 JavaScript 裡能用，驗證卻不過？
因為你寫的不是 JSON，而是 JavaScript 物件實字。先用 JSON.stringify(obj) 轉換一下。
這個工具會上傳資料嗎？ 不會，解析用的是瀏覽器內建的 JSON 解析器，離線也能用。