你的 API 呼叫因 JSONDecodeError: Expecting property name enclosed in double quotes 而失敗。時鐘在滴答作響。資料來自 LLM，而在那個 2000 token 的回應裡，某一個多餘的尾隨逗號毀掉了你整條流水線。
截至 2026 年 5 月，修復格式錯誤的 JSON 檔案最快的方法是使用自動化函式庫，例如 json_repair（Python）或 jsonrepair（npm）。這些工具專為瞬間修復 LLM 產生的語法錯誤而生。至於手動修復，常見的「元兇」是尾隨逗號、單引號或未加引號的鍵——這是違反 RFC 8259 標準的三種最常見情形。
最快的修復方式：針對 LLM 輸出的 json_repair
像 Python 的 json.loads() 這類標準解析器，在設計上就是嚴格的。一個錯位的字元就會觸發 JSONDecodeError，一切都隨之停止。這在 2026 年是家常便飯，因為 LLM 經常把 JSON 包裹在對話文字裡，把回應截斷在句中，或者撒進一些破壞規範的註解。
json_repair 函式庫是首選方案。據 GitHub 顯示，截至 2026 年該專案已獲得超過 4700 顆星。它的工作原理是「猜測」字串的意圖——補上缺失的括號、加上引號，並剝除 JSON 區塊周圍多餘的文字。
Python：改造前後
安裝：pip install json-repair
損壞的輸入：
import json_repair
bad_json = '{"user": "Alice", "status": tru'
decoded_object = json_repair.loads(bad_json)
幕後發生了什麼：json_repair 判斷出 tru 很可能是 true，補上了缺失的右大括號，並回傳了一個合法的 Python 字典。全程零人工介入。
Salvage 模式：資料實在慘不忍睹時
對於更棘手的情況，json_repair（v0.59.5+）提供了 Salvage 模式。正如專案文件所述，這個模式專為被截斷的 AI 回應或損壞的日誌而構建。它可以把陣列強制轉換為物件，或者丟棄那些實在救不回來的項目，從而保證輸出符合你的資料結構。
import json_repair
# Salvage mode for severely truncated data
result = json_repair.loads(
'{"items": [{"id": 1, "name": "Widget"}, {"id": 2, "na',
salvage_mode=True
)
# Result: {'items': [{'id': 1, 'name': 'Widget'}, {'id': 2}]}
# Dropped the incomplete 'na' but saved everything else
npm 替代方案
對於 Node.js 專案，jsonrepair CLI 能完成同樣的工作：
# Fix a file in place
npx jsonrepair broken.json > fixed.json
# Fix a string in a script
const { jsonrepair } = require('jsonrepair');
const fixed = jsonrepair('{"name": "test",}');
手動除錯：找出破壞規範的元兇
當自動化工具也搞不定時，你需要精確定位檔案在何處違反了 RFC 8259。JSON 遠不如 YAML 或 JavaScript 那樣寬容。正如 JSONParser 診斷團隊所解釋的：「解析器在遇到第一個它無法理解的字元時就會失敗，而這往往是幾行之前某個問題的下游症狀。」
三大 JSON 殺手
殺手 1：尾隨逗號
據 DEV Community 的說法，尾隨逗號是解析失敗的頭號原因。在 JavaScript 裡它們沒問題，但在 JSON 陣列或物件的最後一項之後卻是非法的。
// BROKEN - trailing comma after "active"
{
"name": "Alice",
"status": "active",
}
// FIXED - no comma before closing brace
{
"name": "Alice",
"status": "active"
}
殺手 2：單引號
JSON 要求鍵和字串值都使用雙引號（"）。很多 Python 和 JavaScript 開發者會不小心用上單引號（'）。正如 TidyCode 所指出的，這是必須修正的。
// BROKEN - single quotes
{'name': 'Alice'}
// FIXED - double quotes
{"name": "Alice"}
殺手 3：未加引號的鍵
在 JavaScript 中你可以寫 { name: "Alice" }。但在 JSON 裡，每個鍵都需要雙引號。
// BROKEN - unquoted key
{name: "Alice"}
// FIXED - quoted key
{"name": "Alice"}
「Unexpected Token」錯誤
當驗證器報出「Unexpected Token」時，意思是解析器遇到了 NaN、Infinity 或 undefined——這些都是 JSON 不支援的 JavaScript 常數。JSON 只允許 null、true、false 和數字。
// BROKEN - NaN is not valid JSON
{"score": NaN, "result": Infinity}
// FIXED - replace with null or valid values
{"score": null, "result": null}
嚴格解析 vs. 修復解析：何時用哪個
正確的方法取決於你的資料來自哪裡。人工編輯的設定檔應當使用嚴格解析，以迫使作者修正錯誤；而來自 LLM 或 API 日誌的機器生成資料，則需要基於修復的解析。
| 特性 | 嚴格（json.loads） |
修復（json_repair） |
|---|---|---|
| 尾隨逗號 | 拋出 JSONDecodeError |
自動移除 |
| 單引號 | 失敗 | 轉換為雙引號 |
| 被截斷的資料 | 失敗 | 補全未閉合的括號/引號 |
| 註解 | 失敗 | 自動剝除 |
| 最佳用例 | 人工編輯的設定檔 | LLM 輸出、API 日誌 |
用 Pydantic 做結構引導的修復
你可以使用 Pydantic v2 或 JSON Schema 來引導修復過程。給 json_repair 提供一個 schema，工具不僅能修復語法——還能糾正型別（把字串 "1" 轉成數字 1）並用預設值填補缺失的必填欄位。
from pydantic import BaseModel
import json_repair
class User(BaseModel):
id: int
name: str
active: bool = True
# Broken JSON with wrong types
raw = '{"id": "42", "name": "Alice"}'
repaired = json_repair.loads(raw)
# Validate against schema
user = User(**repaired)
# user.id is now int(42), user.active defaults to True
正如 Stefano Baccianella 在其 2025 年的專案說明中所提到的，這種方式針對的是語言模型常產出的那種「大體正確但技術上非法」的 JSON 而做了最佳化。
處理多 GB 檔案而不崩潰
修復一個 10KB 的片段很容易。修復一個 2GB 的檔案則需要一套不會吃光你記憶體的策略。把整個檔案載入記憶體會導致記憶體耗盡（OOM）錯誤。
策略 1：用 ijson 串流處理
對於海量資料集，使用 ijson 逐塊處理資料。正如 Scrapfly 所述，ijson 會增量地處理資料。把它與一個在解析前逐行修復問題的清理腳本搭配使用。
import ijson
# Stream through a large JSON file
with open('huge_broken.json', 'r') as f:
for item in ijson.items(f, 'records.item'):
# Process each item individually
process(item)
策略 2：用 CLI 管道實現最高效率
處理大檔案時最省記憶體的方法是使用 jsonrepair CLI，並把輸出直接管道到一個新檔案：
# Streams repair, never loads full file into memory
jsonrepair large_broken.json > fixed.json
這比把檔案載入 Python 或瀏覽器要省記憶體得多。
結語
得益於 json_repair 這類對 AI 友好的函式庫，修復格式錯誤的 JSON 已不再是體力活。你仍然需要了解 RFC 8259 的基本規則——不能有尾隨逗號、不能有單引號、鍵必須加引號——但在 2026 年面對大規模資料時，自動化才是唯一現實的做法。
工作流程很簡單：先嘗試修復函式庫。如果失敗，再用驗證器精確定位語法錯誤。這樣即使輸入的資料不那麼完美，你的應用也能持續運行。
常見問題
JSON 官方是否支援註解或單引號？
不支援。RFC 8259 標準嚴格禁止註解。單引號同樣非法——鍵和字串只允許使用雙引號。不過，json_repair 這類工具可以自動剝除註解並轉換引號，使檔案能被標準函式庫解析。
如何處理超大且格式錯誤的 JSON 檔案而不崩潰？
使用 ijson 這類串流解析器分塊處理資料。避免把整個格式錯誤的字串載入單一變數。為了最快速度，可使用 CLI 修復工具，把輸出直接管道到磁碟上的新檔案，無需把所有內容都留在記憶體中。
格式錯誤的 JSON 和無效的 JSON 有什麼區別？
格式錯誤（malformed）的 JSON 違反語法規則——缺失括號、鍵未加引號、尾隨逗號——使其無法解析。無效（invalid）的 JSON 遵守所有語法規則，但不符合某個具體的 JSON Schema（例如某個欄位在 schema 裡應為整數，實際卻是字串）。修復格式錯誤的 JSON 屬於結構性修復；修復無效的 JSON 則關乎資料完整性。
我能把 json_repair 和 Pydantic 驗證一起用嗎？
可以。先用 json_repair.loads() 修復語法錯誤，再把修復後的字典傳給你的 Pydantic 模型進行型別驗證和 schema 校驗。這種兩步走的方法同時解決了結構性和語意性問題。
帶有 JavaScript 風格註解的 JSON 怎麼辦？
標準 JSON 不支援註解，但 json_repair 可以自動剝除 // 和 /* */ 註解。如果你需要在設定檔裡保留註解，可以考慮使用 JSONC（帶註解的 JSON）格式，並搭配 json5（Python）這類相容的解析器。
