JSON contract
把 JSON 轉成 TypeScript，但不要相信單一範例
JSON 範例只證明某一次回應，不是 API 的完整承諾。把產生的型別當成可審查的起點。
內容更新： · 維護者與修正回報
逐步判讀可空值回應
將 {"id":"0042","tags":[],"profile":null} 貼入 JSON 轉 TypeScript。識別碼是字串，保留文字型別才能保住前導零；空陣列沒有提供元素型別證據，null 的 profile 也沒有提供 name 或 email 等欄位資訊。不要用推測補成正式契約。
再對照第二份回應：{"id":"0043","tags":["beta"],"profile":{"displayName":"Example"}}。這次能看到字串陣列與物件形式的 profile；仍須向 API 規格確認 profile 是否可為 null，以及 tags 是否可能缺欄。兩份範例依然不足以證明全部規則。
| 情況 | 判讀與下一步 |
|---|---|
| 缺少欄位 | 查核 API 契約後再決定是否使用 optional；缺欄與 null 不同。 |
| 空陣列 | 先取得非空測試資料或查 schema，再決定元素型別。 |
| 看似數字的識別碼 | 前導零或識別值需要完整保留時，維持來源字串。 |
先從使用端的問題開始
轉換 payload 前，先確認 UI 或服務真正會讀哪些欄位。某個範例未出現的欄位，可能是 optional、受權限控制，或只是上游實驗暫時省略。
把不確定性明確寫出來
使用刻意精簡、但能暴露決策的範例：字串或數字識別碼、空陣列、可空值與巢狀物件。把產生的型別放進共用 contract 前先審查。
把 runtime 驗證獨立處理
TypeScript 在 runtime 不存在。產生的 interface 能改善編輯器提示，卻不能證明不可信 JSON 符合型別。錯誤輸入會改變行為或暴露資料時，應在網路邊界驗證。
{"id":"42","tags":[],"profile":null}資料可信度