工作原理
底层算法先计算两个输入的最长公共子序列，再据此推导最短编辑脚本——也就是把一个文本变成另一个所需的最少插入与删除集合。先按行粒度运行是输出可读的关键：一段被重新折行的文字会产生一行改动，而不是两百处字符改动。每处改动被归类为相同、新增、删除或替换，各类计数会被汇总，让你在细读之前先看到改动规模。
行内高亮是第二遍处理。当某行被判定为“替换”时，会把该行的旧版本与新版本再按词粒度做一次对比，并在行内强调差异片段。没有这一步，一个长行里改了一个字符就会把整行标记为改动，什么信息也没提供；有了它，改动立刻可见。这也是配置文件改动可被评审的原因：某一行只改了一个端口号时，只有两个数字被高亮，其余部分不变。
粒度是真实的选择而非外观问题。行粒度适合源码和配置，因为那里的行结构承载语义；词粒度适合被重新折行的散文，那里的换行是噪声；字符粒度用于一个字节也至关重要的场景——哈希、密钥、编码后的数据块——也是唯一能让长 token 中一处字符变化变得可见的设置。切换粒度会重新执行对比，不需要重新输入。
忽略大小写与空白是在对比之前做的规范化，而不是之后。两个文本先被规范化，再做差异计算，这正是让格式化后的文件显示为“无改动”而真实修改依然清晰的原因。代价是高亮输出显示的是规范化后的文本，因此若某处改动仅仅是大小写变化，看起来会像没有改动。当你检查的恰恰就是空白或大小写时，请关闭这些选项。
常见应用场景
- 对比两个版本的配置文件，找出环境之间的差异。
- 检查两份接口响应是否不同，若不同则定位到具体位置。
- 确认格式化或转译工具没有在语义上改动文件。
- 逐字符对比两个长 token 或密钥，找出其中的拼写错误。
- 复核手工编辑过的数值列表，确认只有预期的条目被改动。
- 生成统一 diff，粘贴进代码评审或缺陷报告。
最后更新: 2026-10-14