JSON 的键顺序不参与语义，但参与文本比较。同一份配置，一次由 Go 服务导出、一次由 Node 脚本导出，字段完全等价，diff 出来满屏红绿——因为键被按写入顺序排列。做代码评审、查线上配置漂移时，这类假差异会把真问题彻底埋掉。
排序解决的是哪一种差异
「JSON 格式化」提供递归排序所有对象的键，可选升序降序、可忽略大小写，排完再美化输出。它处理的是键的排列，不动任何值。排序后同样缩进层级、同样保持中文原样，可以直接存成文件送进比较工具。
配合 文本比较 用是完整链路：两份都排序、都统一成 2 空格缩进、都压缩或都美化（两边必须一致，否则纯格式差异又是一屏噪音），然后逐行比。这时留下的每一处不同，都是真的有值变了。
一个必须知道的边界
排序只作用于对象的键，数组内元素顺序保持不变。这不是缺陷：数组在 JSON 里是有序集合，日志列表、菜单项、优先级队列的顺序本身就是数据，自动重排等于改语义。
后果是：如果两次导出的数组内容相同但顺序换了（接口没指定排序字段时很常见），比对仍然会报一片差异。这类要人工判断——先确认业务上顺序有没有意义，没意义就手工对齐后再比，有意义那它就是真变化。
反过来的失败更值得警惕：菜单项、审批步骤、优先级队列这些数组，顺序本身就是配置内容。如果你为了消噪手动把两边数组按字母排齐再比，字段值一处没错、顺序被悄悄改了，比对结果却是完全一致。排序前先把这一类数组挑出来单独看，别让工具替你决定什么算变化。
四步做完一次干净比对
- 两份配置分别粘进 JSON 格式化，确认都能解析成功，报错的那份先修语法。
- 各自执行递归排序键名，选同一档缩进并美化输出。
- 复制进文本比较，只看左右不一致的行。
- 对每处差异回到原始未排序文件核对一遍上下文，避免把排版改动当成配置改动。
什么时候排序帮不上忙
数值写法不同（一边写整数、一边写成带小数点的形式）、字符串里含不可见字符与真换行、一边 null 一边整个键缺失，这三种排序后依然会报差异，而且第三种是真问题。本站不做 JSON Schema 校验，也不做语义级合并，字段该不该存在需要你自己判断。整个过程在浏览器本地完成，生产配置不会被上传服务器、不占每日转换次数。
底线判断：比对前先问一句差异从哪来。来源是不同语言序列化的，排序必做；来源是同一次导出的两个版本，直接比就行，多此一举反而可能盖住顺序变化这个真实信号。结构复杂时先用统计定位，参见 JSON 层级与值统计。