大家好，我不是魚皮。
幸運又不幸，我是一名程式員，他也是一名程式員。
周末，我在開發網站，他在開發遊戲，兩個人一起寫代碼，一起寫 Bug 頭秃，竟也有了一絲别樣的浪漫，好不自在！
今天，他遇到了一個背景的 Bug，遊戲死活啟動不了，我來幫忙排查一下，順便給大家分享點程式設計小知識~
在開始遊戲時，首先要加載一些配置，比如玩家的使用者名、關卡的難度、玩家的初始道具等。
由于遊戲是使用 Java 語言開發的，他把這些配置封裝成了一個對象，代碼如下：
為了開發調試友善，他寫了一個預設的配置；并且為了友善管理預設配置，把它單獨存放到了一個 JSON 格式的檔案中，而不是寫死在代碼裡。
預設 JSON 配置檔案如下：
然後在程式中，讀取該配置檔案中的 JSON 字元串，再通過 <code>Gson</code> 解析庫将 JSON 字元串轉換為 Java 對象，就能擷取到遊戲配置資訊，進而進行下一步處理了。
邏輯代碼如下：
整個流程看起來非常簡單，為啥會報錯呢？
列印出異常資訊，很明顯，是 JSON 解析錯誤了：
仔細一看，哎，這小糊塗，配置檔案竟然輸錯了，行尾少了個必要的引号，當然會解析失敗了！
他表示很無奈，沒辦法，開發的時候配置越堆越多、改來改去，一不注意就少打個字元了。
我笑到：JSON 格式确實是很靈活強大的，我們在工作中，也經常會編寫一些複雜的嵌套 JSON。我倒是知道一個辦法，可以幫助減少 JSON 檔案寫錯的機率。
他不以為然：哦，什麼辦法？用編輯器或者校驗網站檢查一下？
我：那也隻能檢查基本的文法吧，來來來，給你個更好康的神器 —— JSON Schema！
JSON 格式的優點之一就是輕量，其本身并不支援寫注釋，是以沒辦法直接在檔案本身中對字段進行描述。
是以，假如我們用 JSON 來做配置檔案，大多數情況下都要對着文檔來檢視每個字段的類型、限制範圍，才能編寫出正确的配置。這樣做不僅效率低，而且必須要自己來校驗編寫出的配置是否正确，一不小心就寫錯了。
而 JSON Schema 就是為解決此問題而生的，他本身就是 JSON 檔案，用來注解和校驗 JSON 檔案。
舉個例子，上面的遊戲配置中，因為不小心輸錯了字元串數組導緻程式出了 Bug。那可以編寫一個 JSON Schema 來校驗 items 字段是否為合法數組，代碼如下：
在這個檔案中，指定了 GameConfig 的類型必須為 object（對象），且 items 屬性類型必須為 array（數組）。
接下來在要校驗的資料中指定 "$schema" 字段為該校驗檔案位址，比如下列 JSON 配置，故意把 items 字段的值設定為 string（字元串）而非數組：
這樣就能檢查資料是否合法啦！很多主流的編輯器（比如 JetBrains 全家桶）可以自動識别校驗檔案，并且檢查你的 JSON 輸入是否合法。也可以使用 <code>JSON Schema validation online</code> 等線上校驗 JSON Schema 的網頁來檢視效果：
JSON Schema 功能非常強大，除了對字段類型的校驗外，還支援判斷字段是否必填、是否為某個值（支援正規表達式）、最大值最小值、字段個數、枚舉等，甚至支援組合多個判斷條件！
比如還可以給我們的遊戲配置的難度字段添加校驗，必須是 1 到 5 之間的數字，文法如下：
了解什麼是 JSON Schema 後，總結下它的優點：
對資料格式進行描述，提高可讀性，幫助人類了解
讓機器更了解資料，進而提供資料校驗和提示輸入等功能
提供了統一的資料規範文法，便于實作接口格式校驗、自動化測試，甚至還能利用它自動生成代碼！比如 jsonschema2pojo 工具，根據 JSON 生成 Java 類。
總之，利用好 JSON Schema，能大大減少開發者們溝通的成本、保證代碼的品質就對了。畢竟 JSON 可是當今前後端開發中最流行的資料交換格式啊！
看着他一臉懵逼的樣子，我不禁笑到：這個魚皮就是遜啦！
求求給這麼遜的魚皮 點贊 支援一下吧 ❤️
最後再送大家一些 程式設計學習資料：
指路：https://t.1yb.co/qOJG
歡迎閱讀 我的程式設計學習和大廠求職經曆，不再迷茫！
指路：https://t.1yb.co/w66s