JSON 对比

行级 diff 看到的是排版，不是含义

标准的行级 diff 把 JSON 当作散文处理。把文件的缩进从 2 空格改成 4 空格，每一行都会被标记为已更改；把某个键从对象顶部挪到底部，会得到一处删除加一处新增，尽管解析后的值一模一样；把一个长数组折成一行，整段都会亮起。

结构化 diff 会先解析两边，再遍历得到的值。比较开始时排版、键顺序和空白早已不复存在，因此能报告出来的只可能是数据本身的真实差异。这正是它的输出足够短、真的能读完的原因。

用路径而不是行号

这里的每一处差异都对应一个路径，例如 user.roles[2] 或 meta.updated。路径不会因为文档别处的改动而失效，行号会。所以你可以把同一份报告贴进工单或代码评审，一周后它依然指向正确的位置。

三种操作恰好对应树上可能发生的三件事：左边有而右边没有的键是删除，反过来是新增，两边都有但值不同的键是修改。类型变化——某个字段原本是数字 1，现在成了字符串 "1"——同样被报告为修改，而且很值得留意，因为这类问题是下游 bug 的常见来源，任何 schema 校验都未必能拦住。

数组与顺序问题

数组是结构化对比中最需要取舍的地方。默认采用按位置比较：左边的下标 0 与右边的下标 0 相比。对于步骤序列这类有序数据这是正确的，但对于本质是集合的列表就会得出误导性的结果——只要元素换个顺序，每个位置看上去都变了。

「忽略数组顺序」选项会在比较前递归地对两边的数组排序，使其规范化，于是重排过的列表会被判为相等。标签列表、权限集合、没有保证顺序的查询结果都适合打开它。而只要元素位置本身有含义，就应该关掉——因为打开之后，真正的顺序错误会变得完全不可见。