01三种对比粒度，选错就白比
| 对比粒度 | 适用内容 | 输出形式 |
|---|---|---|
| 字符级 | 合同条款、文案改稿、单行文本 | 精确标出增删改的每一个字符 |
| 行级 | 代码、日志、配置文件 | 整行标记新增/删除/修改 |
| 结构级 | JSON、YAML、配置对象 | 按字段路径比差异，忽略键顺序 |
对比 JSON 时如果直接做字符对比，只要键的顺序变了，整段都会标红——这种结果毫无参考价值。结构级对比会先归一化再比字段，只标出真正变化的值。
02场景一：合同 / 文案改稿
改稿场景有个实用技巧：把「修订前」统一放左侧、「修订后」统一放右侧。养成固定顺序后，不会因为两边放反而误判增删方向。
- 1把原版粘到左侧，改后版本粘到右侧。
- 2点「开始比较」，差异会被着色：新增内容、删除内容、修改内容分别标记。
- 3如果只想确认「有没有实质改动」，看差异统计即可；如果要逐条确认，从上往下逐项核对。
- 4注意空白字符。多一个空格或少一个换行也会被标记，先确认这是不是有效改动，避免被噪音干扰。
03场景二：代码改动 review
- 对比两段代码时，先确认缩进方式一致（空格数和 Tab）。缩进不一致会让所有行都显示为改动。
- 重点关注被标记为「修改」的行，而不是「新增」和「删除」的行——新增删除是纯粹的加减，修改才是最容易引入 bug 的地方。
- 重构场景下，把移动过的代码块单独对比，别指望工具能识别「这段代码只是换了个位置」。
- 代码里有大量重复行时，行级对比可能出现错位。这时改用字符级会更准确。
04场景三：JSON / 配置比对
配置文件的差异排查是最需要「结构级对比」的场景。典型例子：两个环境的配置到底哪里不一样？某个字段是什么时候被改的？
- 1把两份 JSON 分别粘进左右两侧。
- 2选择结构对比模式。工具会先解析成对象，忽略键的顺序和排版差异。
- 3查看差异列表：每个变化都会给出字段路径（例如 `server.timeout`）和变化前后的值。
- 4嵌套很深的对象会以路径形式展开，比人工逐层展开快得多。
对比含敏感信息的配置时，注意不要在公共设备上操作，也避免把结果截图分享出去——配置里常有密钥、内网地址这类不应外泄的内容。
05提高对比效率的四个习惯
- 先统一格式：比对前先用格式化工具把两边都格式化一遍，能过滤掉大量无意义的排版差异。
- 分段对比：两份几万字的长文，不如拆成几个章节分别对比，定位更快。
- 保留原始版本：对比是一次性的，但原始文件要留着，方便回溯。
- 先看统计再看细节：差异数量级不对（比如只有 3 处差异却标了 300 处）说明格式没对齐，先解决格式问题。