JSON Schema ⇄ Zod 轉換器

輸入不同。JSON to Zod 是從 API 回應之類的「值範例」推論型別，因此無法得知哪些欄位是必填、字串的 format 是什麼。本工具以 JSON Schema 本身為輸入，所以 required、enum、minLength、format:email 等限制會直接反映到 Zod 的鏈式呼叫（.optional() / .enum() / .min() / .email()）。若您手上已經有 OpenAPI 或 JSON Schema 定義，這條路徑更精確。

兩者的預設值剛好相反。JSON Schema 是「列在 required 陣列中才是必填」，Zod 則是「沒有 .optional() 就是必填」。轉換器會吸收這個差異：轉成 Zod 時，不在 required 中的屬性會加上 .optional()；反向轉換時，沒有 .optional() 的屬性會被收進 required 陣列。

參照不會被展開，$ref 會變成 z.any() 並顯示警告。如果您的結構把共用定義抽到 $defs，請在貼上前先展開，或在產生後手動修改該處。allOf 同樣會提出警告，因為這裡無法表達交集型別，只會轉換第一個子結構。

可以當作骨架，但原本就不在 JSON Schema 裡的業務規則（允許的信箱網域、欄位之間的一致性等）不會被產生出來。另外 pattern 會轉成 z.string().regex()，若原本的正規表示式不相容於 ECMAScript，行為可能會不同。產生後請務必確認內容。

OpenAPI 的 components.schemas 就是 JSON Schema，直接貼上即可同時取得 Zod 結構定義與 z.infer 型別，避免伺服器契約與前端驗證逐漸脫節。

如果專案中是先寫 Zod 結構定義，可以用反向轉換產生 JSON Schema，貼進 OpenAPI 的 components 或文件中。

要取代大量 if 判斷時，只要有既有的 JSON Schema，就能一次產生完整的 Zod 起點，較不會漏掉必填欄位與 enum。

把 LLM 產出的 JSON Schema 直接貼上，轉換成能在 TypeScript 中運作的 Zod 結構定義，同時獲得靜態型別與執行期驗證。

$ref 不會解析參照，會變成 z.any()；allOf 只轉換第一個子結構。if/then/else 與 not 不支援。以上都會在結果下方以警告顯示，請自行補上這些部分。

為了讓一切在瀏覽器內完成，工具不會執行程式碼，而是當作文字剖析。支援 z.object / z.array / z.union / z.enum / z.literal / z.record 與常見的鏈式方法，但透過變數參照的結構定義，或 .refine() 這類任意函式無法用 JSON Schema 表達，因此會被忽略。

JSON Schema 的 pattern 會轉成 z.string().regex()，反向時其內容會回到 pattern。JSON Schema 也允許不相容於 ECMAScript 的正規表示式，直接搬移可能導致行為改變。

本工具用來產生移轉的起點。業務規則與欄位之間的一致性檢查，只要原始結構定義中沒有就不會被產生；用於正式環境驗證前請先確認內容。