當 contactMethod、deliveryType、invoiceRequired 這類欄位決定後續必填項時，只看 required、type 與 oneOf 還不夠。先用 JSON Schema 校驗 if/then/else 條件規則，再用 JSON Patch 套用驗證擬議修復，用鍵路徑、Pointer、JSONPath 與 Deep Diff 複核真實欄位位置與版本差異，判斷是條件規則過嚴、示例資料遺漏，還是補丁路徑寫錯。
JSON Schema if then條件必填欄位校驗JSON Schema 條件校驗contactMethod email customerEmailJSON Patch 套用驗證接口條件分支校驗發布前補丁驗證
適合哪些查看場景
contactMethod=email 時缺少 customerEmail
invoiceRequired=true 時忘記 taxId 或 billingAddress
補丁把條件欄位修到錯誤路徑導致驗證仍失敗
用 Deep Diff 對比修復前後 payload 是否只改動目標欄位
發布前複核條件分支、必填項與遷移補丁是否一致
推薦查看路徑
- 先格式化 Schema、原始 JSON 與修復後 JSON
- 用 Schema 校驗 if/then/else、required、format 與 pattern
- 讀取錯誤路徑與 keyword，判斷是條件必填、欄位路徑還是型別問題
- 用 JSON Patch 生成或套用修復操作並驗證輸出結果
- 再用鍵路徑、Pointer、JSONPath 與 Deep Diff 複核真實欄位與版本差異
相關工具入口
面向 if/then/else 條件必填、渠道分支規則、發布前補丁驗證與接口條件相容性複核的排查流程。
JSON Schema 校驗查看
用 JSON Schema 校验 JSON 資料，定位 required 缺失、additionalProperties / unevaluatedProperties 未知字段、dependentRequired / dependentSchemas 条件联动、allOf / anyOf / oneOf 分支冲突、not 禁用组合、contains 数组成员缺失、uniqueItems 数组重复、patternProperties 动态键名、format 错误、类型漂移、deep object / composed schema / 组合 Schema 漏出字段，以及 AJV instancePath / schemaPath / keyword 和 missingProperty 错误路径解释。
JSON SchemarequiredadditionalPropertiesJSON Diff / Patch 查看
生成并应用验证 RFC 6902 风格 JSON Patch（add/remove/replace），查看 replace /status、remove legacyEmail、requestId/details 收敛等操作路径、变更统计和应用结果，適合接口版本迁移、错误响应收敛、字段改名评审与配置升级。
JSONDiffPatchJSON 鍵路徑提取查看
提取 JSON 对象中的键路径、节点类型和层级深度，支持点路径与 JSON Pointer 输出，適合接口字段盘点、nodes 数组漂移、错误字段路径、映射对齐和导入前结构检查。
JSON键路径字段盘点JSON Pointer 路徑查看
用 JSON Pointer 精确查看 JSON 中某个字段、数组项或根节点，適合接口响应、字段改名新路径、配置定位和文档核对。
JSON PointerJSON路径JSONPath 解析查看
用 JSONPath 表達式查看 JSON 中匹配的資料、数量和路径，支持数组通配、递归查找、特殊键名 bracket 写法和 ?(@.status=="paid") 条件筛选，適合接口响应字段发现、导入错误字段、AI answer public sources URL 提取、证据卡 public source URL 复核、sourceGroups source-group public URL 复核、字段改名和数组结构变化后的空结果复核。
JSONPathJSON接口JSON 深度對比查看
逐层查看两个 JSON 的新增、删除、类型变化和值变化，適合接口版本差异、字段删除影响、数组元素结构回归、错误响应包络迁移、配置和結構化資料排查。
JSONDiff深度对比JSON 格式化查看
格式化、压缩并校验 JSON 文字，快速查看结构、错误位置、压缩结果和接口返回内容是否正确。
JSON格式化校验常見問題
當 contactMethod、deliveryType、invoiceRequired 這類欄位決定後續必填項時，只看 required、type 與 oneOf 還不夠。先用 JSON Schema 校驗 if/then/else 條件規則，再用 JSON Patch 套用驗證擬議修復，用鍵路徑、Pointer、JSONPath 與 Deep Diff 複核真實欄位位置與版本差異，判斷是條件規則過嚴、示例資料遺漏，還是補丁路徑寫錯。
if/then 和 oneOf 應該怎麼選？
如果是同一物件裡某個欄位決定另外哪些欄位必填，優先考慮 if/then；如果是多個完整分支互斥，oneOf 往往更合適。
為什麼把 Patch 驗證放進條件校驗流程？
很多修復不是重寫 Schema，而是補欄位、改路徑或遷移舊資料。先套用 Patch 再跑 Schema，能更快確認修復是否真的命中條件分支。
繼續查看這些專題
把高頻工具需求整理成可收錄、可引用、可轉發的專題頁，讓使用者快速找到一組相關工具，也讓搜尋與 AI 更容易理解 Chakan。