Visual Studio Code 會在 JSON 檔案副檔名為 .json 時自動進行驗證，並以紅色波浪線與問題面板條目標示語法錯誤，同時顯示解析失敗所在的行與欄位。這個內建行為來自 VS Code 內建的 JSON 語言服務，它理解與 JavaScript 執行環境強制執行相同的語法，因此大多數簡單的錯誤會在你存檔的當下立即顯示。問題在於 VS Code 的錯誤訊息很短，有時甚至很晦澀，而且只與你當下檢視檔案的位置有關。當你在除錯一個 500 行的 API 回應或一個深度巢狀的設定檔時，一個模糊的「Unexpected token」是不夠的——你需要精確的行號、精確的欄號，以及解析器實際預期內容的清楚說明。這正是專門的 JSON Validator 能為你提供的功能，它在你的瀏覽器中執行，不需要安裝任何擴充套件，也不需要開啟任何專案。
為何 VS Code 的內建 JSON 驗證有時不夠用
VS Code 內建了一個 JSON 語言服務，在你開啟副檔名為 .json 的檔案時立即啟用。當你輸入的同時，解析器會即時根據標準語法檢查你的內容並標示出問題。對於像 package.json 或 settings.json 這種小型、手寫的檔案，這確實非常實用——你一存檔，編輯器就已經抓到多餘的逗號或遺漏的大括號。
但內建驗證器有其限制，一旦你的 JSON 不再是小型或友善的檔案就會顯現出來：
- 錯誤訊息過於精簡。「Unexpected token」幾乎沒有告訴你解析器反對的是哪個字元或哪個結構。
- 沒有結構概覽。VS Code 只會告訴你 JSON 有問題，但不會告訴你它的巢狀深度有多深，或包含多少鍵。當一個 payload 看起來可疑但解析通過時，你沒有快速的方法能察覺到意外的深度或非預期的形狀。
- 檔案偵測可能失敗。如果 VS Code 無法將檔案辨識為 JSON（沒有 .json 副檔名、檔案關聯錯誤、內容混雜），驗證器根本不會執行。
- 某些合法的 JavaScript 不是合法的 JSON。註解、尾端逗號與單引號在 JavaScript 物件字面值中是合法的——把教學中的程式碼片段貼到 VS Code 時，編輯器可能會標記出對你來說看起來完全正常的語法。
面對這些情況，一個專注的驗證器能為你提供第二意見，它只圍繞著一個問題：這個 JSON 是否格式正確，若否，問題出在哪裡？
常見讓 VS Code 使用者踩坑的 JSON 語法錯誤
標準 JSON 受 RFC 8259 規範，它以每天都會讓開發者感到意外的方式嚴格規定。最常見的 JSON 檔案在 VS Code（或任何其他地方）驗證失敗的原因包括：
- 未加引號或使用單引號的物件鍵。{ name: "Ada" } 看起來合理，但它是非法的。鍵必須是雙引號字串：{"name": "Ada"}。
- 字串值使用單引號。'hello' 在 JavaScript 和 Python 中沒問題，但在 JSON 中不行。請使用 "hello"。
- 尾端逗號。{"a": 1, "b": 2,} 會被拒絕。最後一個元素後的逗號在語法中沒有容身之地。
- 註解。// 單行註解 和 /* 區塊註解 */ 不屬於 JSON，儘管大多數編輯器在 JavaScript 中允許它們。JSON5 和 JSONC 是獨立的格式；原生的 JSON 不允許註解。
- NaN、Infinity 和 undefined。這些是 JavaScript 的便利值，不是 JSON 的值。數字必須是有限的十進位表示。
- 不平衡的方括號或大括號。在 400 行的檔案中，某處少一個 ] 或 } 會在遠離實際打錯位置的地方產生令人困惑的錯誤。
| 錯誤 | 看起來像 | 為何失敗 |
|---|---|---|
| 單引號字串 | 'name': 'Ada' | RFC 8259 要求鍵和字串值都使用雙引號 |
| 尾端逗號 | {"a":1,} | 逗號必須分隔項目；最後一個元素後不能有逗號 |
| JSON 中的註解 | // note | JSON 語法中未定義註解 |
| 未加引號的鍵 | {name: "Ada"} | 所有鍵都必須是加上引號的字串 |
| NaN 值 | {"x": NaN} | NaN 不是有效的 JSON 數字 |
以上每一種情況都會產生不同的解析器錯誤，VS Code 簡短的訊息很少會指出被違反的規則。一個能顯示解析器完整訊息並標示行與欄的驗證器，讓你直接跳到問題點，而不用靠肉眼掃描整個檔案。
使用 JSON Validator 工具驗證 JSON
當你需要一個明確的答案，判斷一段 JSON 是否格式正確——而且不需要安裝擴充套件或開啟專案——JSON Validator 工具會執行你的瀏覽器已經在用的解析器，並以平實的語言回報結果。以下是確切的工作流程：
- 將你的 JSON 貼上或輸入到輸入框中。從 VS Code 複製檔案內容並貼到驗證器中，或直接輸入。輸入框接受任何能放入的尺寸。
- 立即讀取判定結果。綠色指示燈確認 JSON 有效。如果解析失敗，會出現紅色錯誤，並附上解析器本身的訊息，以及（在引擎提供的情況下）解析中斷的精確行與欄——例如，「Invalid JSON at line 3, column 7.」。不同瀏覽器的措辭會略有不同（Chrome 和 Edge 中的 V8、Firefox 中的 SpiderMonkey、Safari 中的 JavaScriptCore），該工具會將回報位置的引擎資訊正規化。
- 針對有效的 JSON 檢視結構報告。一旦解析器滿意，驗證器就不再只是紅綠燈測試，而是開始進行診斷。它會回報頂層類型（物件、陣列、字串、數字、布林值或 null）、最大巢狀深度、所有層級的鍵總數、物件與陣列的數量，以及字元總數。
第三個步驟是 VS Code 永遠不會做的事。在修正語法錯誤後，你可以確認結果在結構上是否如你所預期——一個具有三個鍵的扁平設定、一個本應為扁平卻深度巢狀的回應，或一個悄悄從 50 個項目增長到 500 個項目的清單。
閱讀結構報告
結構報告的存在是因為有效的 JSON 仍然可能是錯誤的 JSON。API 可能回傳 200 狀態，但其 payload 的形狀與你的 TypeScript 類型不符。設定檔可能解析無誤，卻不小心把陣列巢狀在陣列中再巢狀在陣列中。這份報告回答四個實務問題：
- 頂層類型是什麼？物件、陣列或基本型別——當你預期一種卻得到另一種時很實用。
- 它的巢狀深度有多深？過深的深度是一個警訊。如果你的結構描述（schema）預期兩層卻看到十層，上游一定發生了問題。
- 總共包含多少個鍵？一個包含 4,000 個鍵的回應很可能不是你的程式碼設計要處理的。鍵的數量是粗略的 payload 大小指標。
- 內部有多少個物件和陣列？有助於你發現重複、過大的區段或被剝除的封裝層。
驗證器刻意保持你的文字不變，讓你能在不意外編輯格式的情況下修正語法。如果你還想對同一份資料進行美化排版或壓縮，那是另一項工作——驗證器純粹專注於正確性檢查、錯誤定位與結構診斷。
JSON Validator 與 JSON Formatter 的比較
這兩個工具回答不同的問題，知道你需要哪一個能節省時間。
| 功能 | JSON Validator | JSON Formatter |
|---|---|---|
| 根據 RFC 8259 檢查語法 | 是 | 是 |
| 回報錯誤的行與欄 | 是 | 是 |
| 美化排版 JSON | 否 | 是 |
| 壓縮 JSON | 否 | 是 |
| 回報結構統計資料（深度、鍵數） | 是 | 否 |
| 重新格式化輸入 | 否 | 是 |
如果你是要除錯「為什麼這個無法解析」，請使用驗證器。如果你是要清理縮排或為了網路傳輸而移除空白字元，請使用格式化器。當你特別不希望文字被更動時，驗證器就是正確的選擇。
隱私、精確度與 RFC 8259 標準
JSON Validator 中的驗證完全在你的瀏覽器原生解析器中執行，該解析器實作了 RFC 8259 中定義的語法——這是 JavaScript 執行環境、Node.js 和大多數生產環境 JSON 函式庫所遵循的同一標準。沒有寬鬆的猜測、沒有自動修復，也沒有伺服器上傳：你的 JSON 從未離開這個頁面，這在你檢查權杖、憑證或私人 API 回應時非常重要。
有一個值得了解的注意事項。JSON 數字會被讀取為 IEEE-754 雙精度浮點數，因此大於 2^53 的整數在解析時會失去精度。一個綠色的「Valid JSON」判定只確認你的資料在語法上是正確的，並不保證 64 位元的識別碼完整無損。如果你的 payload 使用了大整數（資料庫 ID、Snowflake ID、OAuth nonce 值），請將驗證器的輸出視為語法檢查，並使用另一個工具驗證數值完整性。
深度巢狀的輸入也能被安全處理：即使是會讓天真的遞迴走訪器當機的病態結構，也會被引擎的解析器攔截並回報為錯誤，而不是凍結你的分頁。這使得驗證器適用於不常見的輸入——從 REST 客戶端貼上的片段、格式錯誤的 webhook payload、截斷的日誌——在這些情況下你真的不知道即將輸入什麼。
如需更深入的瞭解，請參閱 JavaScript Key Code Finder：解碼 KeyboardEvent 欄位。
如需更深入的瞭解，請參閱 基於型別對應的 JSON 轉 XML 替代方案。