文本差异检测

使用方法

1. 打开页面时两侧已经填好同一份接口文档的旧版与新版，结果区直接给出比对结果，不用先点按钮。左侧「旧文本」放改动前的内容，右侧「新文本」放改动后的内容。
2. 「比对粒度」默认选逐行比对：以换行符为界把文本切成行，一行对一行地找增删，适合代码、日志、配置文件这类一行一条记录的内容。
3. 短文本（比如一句话的修辞改动）可以切成逐字符比对，它按字素逐个比较，会把改动定位到具体哪几个字，而不是笼统地标成「整行改了」。
4. 「保留上下文行数」默认 2：改动行上下各留 2 行未改动的内容作参照，中间跳过的部分折叠成一行省略号；填 0 就只看改动行。
5. 「忽略行尾空白」用于对付编辑器自动去掉行尾空格造成的假改动；「忽略大小写」用于对付变量名大小写被统一的情况。两者都只影响比较时的判定，显示出来的仍是原文。
6. 点「开始比对」（或在任一文本框里按 Ctrl + Enter）刷新结果；点「交换两侧」把新旧对调，方便确认某一行到底是加进来还是删掉的。

这个文本差异检测能解决什么问题

一是核对两版配置到底改了哪几行。运维改完 nginx 或应用配置后，把改动前后的文件各贴一次，比肉眼从头到尾读一遍可靠得多，也不会漏掉只差一个字符的那种改动。

二是确认接口字段有没有被悄悄加删。前后端联调时字段名差一个字母，或者有人顺手多返回一个 captcha，靠人工比对很容易滑过去；逐行比对会把新增那一行单独标绿。

三是排查「看起来一样」的两段文字为什么程序判不相等。这类问题九成出在行尾：从 Windows 复制来的文本每行尾多一个 \r，或者行尾多了几个看不见的空格。文本差异检测会先把行尾统一成 \n 再比，一测就知道是不是这个原因。

四是把改动记录成一份可粘贴的清单。点「复制差异结果」拿到的是带 + / - 前缀的纯文本，可以直接贴进工单、提交说明或聊天记录里。

本页不做这些事：不做三方合并、不生成补丁文件（patch）、不比较两个文件夹、不读取本地文件。它只回答一个问题——这两段文本之间，多了哪几行、少了哪几行。

比对原理：先归一化行尾，再用 Myers 差分

整页只做三件事：切分、求最短编辑脚本、上色渲染。真正有讲究的是中间那一步。

第一步必须先归一化行尾，否则会全军覆没。不同系统给换行打的标记不一样：Windows 是 CRLF（两个字符：回车 \r 加换行 \n），Linux 与 macOS 是单个 LF，老式 Mac 是单个 CR。假设你手上有两段完全一样的 5 行文字，一段来自 Windows、一段来自 Linux，不归一化就直接按行比，每一行的行尾都差一个 \r，于是5 行全被判为改动；实测 1000 行的文件会凭空多出 1000 个 \r，也就是 1000 行全部「不同」。本页在任何比较之前先执行 text.replace(/\r\n?/g, '\n')，把 CRLF 和落单的 CR 统统折成 LF，再切行。

第二步是求最短编辑脚本，本页用 Myers 差分。求「把旧文本变成新文本最少要删几行、加几行」，本质是找两个序列的最长公共子序列（LCS）。最直白的做法是动态规划：开一张 n × m 的表，逐格填数。它的复杂度是 O(n × m)——两边越长就越慢，而且慢得是平方级的。两篇各 10000 行的文本，表就有 1 亿格；用 16 位整数存这一张表要 190.7 MB，还没算填表的时间。而参考实现里 Myers 的算法复杂度是 O((N + M) × D)，其中 D 是编辑距离（删的行数加上加的行数），与文本长度不成平方关系，只与实际改动了多少有关。同样 10000 对 10000 行，如果只改了 10 处，Myers 的上界是 (10000 + 10000) × 10 = 200000 次运算，比 LCS 的 1 亿格快了约 500 倍；反过来若两篇几乎完全不同，D 逼近 N + M，Myers 也会退化到与 LCS 同量级。这正是 git 这类工具内部选 Myers 的原因：真实改动通常是稀疏的。

第三步，逐行还是逐字符，取决于你关心什么。逐行比对把「一个字符不同」放大成「整行删除 + 整行新增」，读数更清爽，适合结构化文本；但如果两段是自然语言的一段话，整行都会被标成改动，信息量为零。这时切到逐字符比对更有用。逐字符的关键是不能按 UTF-16 码元切：一个「家庭」表情 👨‍👩‍👧‍👦 由 4 个表情加 3 个零宽连接符组成，在 UTF-16 里占 11 个码元，硬切会把它劈成好几段，渲染出乱码方块。本页用 Intl.Segmenter 按字素（grapheme）切分，上面那个表情会被当成一个整体；一面国旗 🇨🇳 占 4 个码元，同样只算 1 个字素。

为什么给行数上限。Myers 虽然快，但它的记录表开销随 D 增长（要保存每一步的 V 快照），两侧行数越多、差异越碎，内存占用越高。这个文本差异检测把每侧限制在 5000 行，超出的部分只比对前 5000 行并在提示区写明，而不是让页面卡住；编辑距离 D 超过 4000 时也会中止行级比对并提示改用更细的粒度。

完整示例（数值仅作演示）

示例条件与页面打开时完全一致：左侧 6 行旧文档、右侧 7 行新文档、逐行比对、上下文 2 行。实测结果：

• 未改动 3 行：第 1 行的标题、第 3 行的请求方法、第 5 行的返回说明；
• 新增 4 行：新版把 /api/user/login 改成 /api/v2/user/login、参数里加了 captcha、超时从 30 秒改成 60 秒，并多了最后一行备注；
• 删除 3 行：对应的旧地址、旧参数、旧超时各删掉一行；
• 编辑距离 D = 4 + 3 = 7，行相似度 3 ÷ 7 = 42.9%；
• 这个规模下 Myers 的上界是 (6 + 7) × 7 = 91 次运算，而 LCS 动态规划要填 6 × 7 = 42 格——小文本上两者都不值一提，差距要到上万行才显出来。

注意「修改一行」在 diff 里的表示是删一行 + 加一行，所以三处修改贡献了 3 次删除和 3 次新增，再加上末尾纯新增的 1 行，就是上面的 4 加 3。

行数规模、LCS 与 Myers 对照表

下表两列「上界」都在同一输入下计算：LCS 一列是动态规划表格的格数 n × n（内存按 16 位整数折算），Myers 两列分别按编辑距离 D = 10 与 D = 1000 估算 (N + M) × D。数字能直接说明「为什么不能拿 LCS 去比大文件」。

看第 8 行与第 6 行的对照：同样是「两篇各一万行」，如果实际只改了 10 处，Myers 只要 20 万次运算，而 LCS 要先开出 1 亿格、占 190.73 MB。差距不是几个百分点，而是三个数量级。

边界与精度说明

• 每侧 5000 行是硬上限。超出的部分不会被比对，页面会在提示区写明「只比对了前 5000 行」。要处理更大的文件，先用 格式化 或按模块切分，再分段比对。
• 行尾统一成 LF，且这一步不可关。它是无条件执行的，没有开关——关掉只会让两段内容相同的文本被报成完全不同，没有使用价值。
• 空白差异只在你勾选时才忽略。「忽略行尾空白」只去掉每行末尾的空格和制表符，行首的缩进差异仍然算改动；制表符与空格在行内混用也仍算改动。
• 「忽略大小写」只影响判定，不改显示。开启后 Token 与 token 被视为同一行，但结果区显示的仍是你原本输入的写法，方便核对真实内容。
• 字素切分只在「逐字符比对」下生效。逐行比对以换行为界，行内是一个整体，不做字素拆分。
• 相似度是「未改动行数 ÷ 两侧中较多的行数」。它是一个粗略指标，不衡量字符级相似度：一行里改了一个字，也算这一行整体未变还是变更？本页按「变更」计，所以相似度只会偏低、不会虚高。
• 本工具不产生补丁文件。「复制差异结果」复制的是带 + / - 前缀的纯文本，不是 git 能直接 apply 的 unified diff。

常见问题

相关工具

• 字符串长度统计：先量出两段文本的字符数与字节数，判断差异是不是出在不可见字符上。
• 正则测试工具：用模式把要关注的行筛出来，再拿筛选结果做比对。
• Git速查表：命令行里的 git diff 与这里的结果是同一套差分逻辑，参数含义可以对着查。
• JSON格式化工具：把一整行 JSON 展开成缩进结构，多行化之后再回来逐行比对更清楚。
• HTML格式化：把压缩成一行的标签展开，方便按行核对结构改动。
• CSV格式化：对齐列宽后再比对表格文本，比逐字符盯着找差异省事。
• Markdown转HTML：改完文档转一次，比较渲染前后的结构差异。
• 开发者工具：查看全部开发者工具。