JSON 修復實戰：從錯誤位置到可信資料的完整排查流程

API 日誌、從 JavaScript 複製出來的物件，以及人工編輯過的設定檔，常常只是「看起來像 JSON」。修復的目標不是讓錯誤訊息消失，而是在不改變業務含義的前提下，得到可驗證、可重現、可信任的資料。

一、先保留原始輸入

不要覆蓋唯一副本。先保存原始文字、來源、時間與請求 ID。日誌可能包含 token、電子郵件或內部網址；使用工具前應移除不需要的敏感欄位。保留原文可以讓你比較每一步修復，也能在修改含義不對時回到證據來源。

二、從第一個錯誤開始

常見問題包括單引號、屬性之間缺少逗號、把布林值寫成 True，以及最後一個成員後多了一個逗號。解析器通常只回報第一個無法繼續的位置，所以不要憑感覺一次修改整份文件。建議按順序處理：字串與 key 改成雙引號、補齊逗號、把布林值與 null 改成標準小寫、移除尾端逗號。

可以把候選內容放入 JSON 修復工具，再把輸出送到 JSON 驗證器 獨立覆核。

三、不要用簡單取代刪註解

// 和區塊註解屬於 JavaScript 語法，不是標準 JSON。但這些符號也可能出現在字串內，例如網址。可靠的修復流程應先辨識字串邊界，再移除真正的註解。如果註解包含業務說明，應移到文件或明確欄位，而不是靜默刪除。

四、截斷資料不能安全猜測

網路中斷可能只留下半個陣列或尚未完成的欄位。工具可以補括號，卻不知道缺少的 ID、物件或陣列成員。即使語法變有效，也不代表資料完整。正確做法是重新取得來源資料，或將紀錄標記為不完整。

重複 key、前導零、超大整數、日期字串、NaN 和 Infinity 也需要人工判斷。不同解析器可能保留不同的重複值，而超過 JavaScript 安全整數範圍的識別碼通常應以字串傳遞。

五、完成四層驗收

第一，確認瀏覽器與後端解析器都能讀取。第二，檢查根節點、必填欄位與型別。第三，用 JSON Diff 比較修復前後，特別注意金額、權限、狀態與 ID。第四，把損壞樣例加入回歸測試，避免同樣問題再次出現。

總結

可靠的 JSON 修復流程是：保留原文、修第一個錯誤、記錄變化、再次驗證、核對業務含義。自動工具適合處理標點、引號、註解與標準字面量，但不能替代對缺失資料和業務規則的判斷。