文本对比
把改动前后的两段文本按行做 LCS 对比：绿色是新增、红色是删除，灰色 ~ 前缀标出被修改的行。
--- 分隔）
怎么用
在输入框里粘贴两段文本，中间单独占一行写三个减号 --- 当分隔线，前半段当作旧版本、后半段当作新版本。输出里每一行都带行号：+ 开头是新增，- 开头是删除，~ 开头是修改；a 列是旧文本的行号，b 列是新文本的行号，空白表示这一行在那一侧不存在。分隔线也可以写成 ==== 或 >>>>，效果一样。
两个选项会影响结果：忽略首尾空白把每行两端的空格和 Tab 去掉再比，适合处理「编辑器自动去掉了行尾空格」，但行内部的空格仍然算差异；忽略大小写把两边都转成小写再比，适合配置项和标识符，代价是会掩盖 Name 和 name 这种真正的拼写变化。
为什么长文本会慢：LCS 的 O(n×m)
逐行对比的标准做法是先求两个行序列的最长公共子序列（LCS），再据此反推哪些行是新增、哪些是删除。求 LCS 的动态规划要填一张 行数 × 行数 的表：两边各 1000 行就是 100 万次单元格计算，各 5000 行就是 2500 万次，浏览器主线程会被占满，页面像卡死一样。
所以这里有规模保护：两边行数之和超过 3000 行，或行数乘积超过 200 万，就自动切换成简单的行对行比较，并在结果开头用一行 # 注释说明。降级后是「大致对齐」而不是最少的编辑步骤——同一处改动可能显示成好几组增删，但足够一眼看出差异，而且不会卡住浏览器。再大的数据建议直接用 git diff。
常见的坑
- 行尾空格看不见。两个文件看起来一模一样却报差异，多半是行尾有空格或 Tab。勾上「忽略首尾空白」再看一次。
- 末尾换行。文件最后有没有换行符会决定是否多出一个空行，很多编辑器保存时默认补一个。这属于真实差异，git 也会报。
- 缩进风格变了。空格缩进换成 Tab 缩进会把整份文件标成全改。这种情况先统一缩进，再对比才有意义。
- 行内改动不如字符级 diff 直观。一行里只改了一个词，也会显示成一删一增整行。要看字符级差异请用编辑器的行内高亮。
常见问题
为什么文本一长对比就变慢？
因为用的是 LCS，复杂度是行数相乘。两边各 2000 行是 400 万次比较，各 1 万行就是 1 亿次，浏览器单线程扛不住。本站两边合计超过 3000 行、或行数乘积超过 200 万就自动降级成简单的行对行比较。
「忽略首尾空白」和「忽略大小写」有什么区别？
忽略空白只管每行两端的空格和 Tab，行内的空格照旧参与比较；忽略大小写是把两边统一转成小写再比。两个选项可以同时勾，判定顺序是先归一化再比较。
为什么文件末尾多一个换行也会被标成差异？
最后那个换行符会让切分出来的行数多 1，于是末尾显示一行新增或删除。这是真实差异而不是工具的误判，但通常无意义，忽略即可——也可以配合「忽略首尾空白」让那个空行照样显示为空行。
被修改的行为什么显示成一红一绿两行？
逐行 diff 只判断整行相同还是不同，没有做行内字符级比较。所以一行改动会被拆成删除旧行和新增新行两条记录，本站再把相邻同位置的删增额外标上灰色 ~ 前缀，方便你一眼看出这是改动而不是纯插入。
对比结果会上传到服务器吗？
不会。算法就在这个页面里跑，断网后刷新页面依然可用。按 F12 看网络面板也不会发现上传请求——这正是这个站所有工具的承诺。