JSON Patch 生成与应用

只传改动而不是整份文档，是 PATCH 请求的常见做法。这页把两份 JSON 的差异生成成标准补丁（RFC 6902 的 add / remove / replace 列表，或 RFC 7386 的 merge patch），也能反过来把补丁应用到原文档上验算一遍。全部在你的浏览器里算，数据不会发给服务器。

RFC 6902：一串操作

补丁是个数组，每一项是一次操作：{"op":"replace","path":"/name","value":"李四"}。路径用 JSON Pointer 写，数组下标也是路径的一部分（/tags/2），末尾追加写成 /tags/-。表达力强，能精确到数组的某一个元素，代价是补丁本身不太好读。

RFC 7386：一份「只写要改的字段」的文档

补丁长得和原文档一样，只是把要改的字段写出来，null 表示删除这个字段。好写好读，但有两个硬限制：删不掉值本来就是 null 的字段，而且数组只能整个替换，改不了其中一个元素。配置类接口用它很合适。

path 里的 / 和 ~ 要转义

JSON Pointer 规定 ~ 写成 ~0、/ 写成 ~1。所以键名 a/b 的路径是 /a~1b。本页生成和应用时都按这个规则处理，手写补丁时注意别漏。

test 操作是干什么的

{"op":"test","path":"/version","value":3} 会在打补丁前先核对当前值，对不上整个补丁就失败。用来做乐观锁：并发改同一份文档时，先 test 版本号，避免后改的人把前面的改动盖掉。

数组的差异为什么看起来啰嗦

本页对数组按下标逐个比较，中间插入一个元素会导致后面全部错位、生成一长串 replace。这是 RFC 6902 生成器的通病。真要对数组做结构化比较，用 JSON 对比 看差异更直观。

相关工具

JSON 对比、JSONPath 测试、JSON 结构处理、JSON 树形查看。