文本 Diff 对比

import 'github-markdown-css'

什么是文本 diff 工具？

这个工具用于比较两段文本的逐行差异。你把旧版本放在左侧，把新版本放在右侧，页面会输出：

• 新增行数 added
• 删除行数 removed
• 成对修改行数 changed
• 未变化行数 unchanged

当前实现的重点是“行级可读性”，而不是 Git 那种字符级高亮。它会先做最长公共子序列（LCS）对齐，再把连续的删除块和新增块尽量配对成 changed 行。因此，它很适合审查文案、配置、日志片段和接口响应，但不适合做复杂源码合并。

另外，工具会把 和 统一为 ，因此来自 Windows、macOS、Linux 的文本在比较前会先被归一化。

适合的使用场景

• 比较 API 返回值快照。
• 审校文案或 Prompt 版本。
• 核对配置改动。
• 追踪日志片段差异。

参考资料

• GNU diffutils Manual 解释了经典文本比较术语和输出模型。
• Git diff 文档说明了常见的差异展示语义。
• Longest common subsequence 条目可帮助理解本工具的核心对齐思路。

使用说明

1. 准备两段文本

• 左侧 Before：旧版本、原始版本。
• 右侧 After：新版本、目标版本。

可以直接粘贴多行内容，例如配置、日志、接口响应或文案。

2. 查看顶部统计卡片

页面会实时统计：

• added：只出现在右侧的行。
• removed：只出现在左侧的行。
• changed：删除行和新增行被成对配对后形成的修改行。
• unchanged：左右完全相同的行。

3. 阅读差异表格

结果表会展示左右行号以及每一行的状态。你可以快速定位：

• 哪一行被保留。
• 哪一行只在旧文本中存在。
• 哪一行只在新文本中存在。
• 哪些删除与新增被视为“修改”。

推荐用法

1. 先把两边文本都整理为一行一条记录。
2. 如果是 JSON，建议先经过 JSON 格式化工具再比较。
3. 先看统计卡片，再回到表格逐行确认。

参考资料

• GNU diffutils Manual
• Git diff
• Longest common subsequence

常见问题

为什么这个工具不是字符级高亮？

因为当前实现是逐行对比。它更强调“哪一整行变了”，而不是在单行内部标出每个字符的细粒度修改。

changed 是怎么来的？

当连续差异块里同时存在删除行和新增行时，工具会按顺序把它们配对，形成 changed。这是一种可读性优化，不代表做了语义相似度计算。

为什么重复行很多时结果看起来不直观？

LCS 对齐在面对大量重复内容时，本来就可能出现多种合法答案。当前实现会选择其中一种稳定路径，但不一定和你的人工直觉完全一致。

空白差异会不会算改动？

会。当前没有“忽略空白”或“忽略大小写”开关，因此空格、缩进、空行变化都会参与比较。

能导出 patch 或 unified diff 吗？

目前不支持。页面只提供可视化表格和汇总数字。

参考资料

• GNU diffutils Manual
• Git diff
• Longest common subsequence

典型示例

1. 文案改版

把旧版标题粘贴到左侧、新版标题粘贴到右侧，可以快速看出是“整体重写”，还是只改了几个关键句。

2. 配置项核对

.env 示例、YAML 片段、请求参数列表都适合先整理成一行一条，再用这个工具核对增删改。

3. Prompt 版本管理

当你在优化 AI 提示词时，可以把旧 Prompt 和新 Prompt 放进来，快速确认哪些限制条件、角色设定、输出格式发生了变化。

4. 快照回归检查

把接口返回值经过 JSON 格式化后，再放到文本 diff 中，可以更快识别字段新增、字段删除或文案变化。

组合建议

• 结构化数据先用 JSON 格式化，再做 diff。
• 时区转换结果或图片转换日志，也可以先整理成多行文本后再比较。

参考资料

• Git diff 的常见工作流与这里的使用习惯很接近。
• GNU diffutils Manual 提供了大量文本比较案例。
• Longest common subsequence 解释了为什么“相同内容对齐”是比较的基础步骤。

行级 diff 的工作原理

当前工具先把输入拆成“按行组成的数组”，再基于最长公共子序列（LCS）找出左右文本中可以稳定对齐的公共部分。未能对齐的部分会进入差异块，随后按下面的规则生成结果：

1. 完全相同的行记为 equal。
2. 只存在于左侧的行记为 remove。
3. 只存在于右侧的行记为 add。
4. 当同一个差异块同时包含删除与新增时，工具按顺序配对为 change。

这也是为什么它是“行级阅读器”，不是“语义理解器”。如果一段文本发生了大规模重排、重复行很多、或单行里只改了几个字符，你看到的结果可能更接近传统 diff，而不是人脑概括。

为什么换行符会先被统一？

Windows 常见 CRLF，类 Unix 系统常见 LF。当前实现会先统一换行风格，避免同一内容仅因平台不同而出现大量伪差异。

参考资料

• GNU diffutils Manual
• Git diff
• Longest common subsequence

使用技巧

先做预处理再比较

结构化数据建议先格式化；日志建议先去掉无关时间戳；配置建议一行一项。这样能减少噪声，让 changed 更有解释力。

留意“假差异”

以下内容很容易造成视觉误判：

• 行尾空格。
• 空行数量变化。
• 缩进变化。
• 大段内容整体移动位置。

changed 不等于“最聪明的配对”

当前工具只是顺序配对删除和新增，不会计算字符串相似度。所以复杂重写时，请把它当作“可读的近似结果”。

大文本要分块处理

LCS 属于典型的二维动态规划思路，文本越长，计算成本越高。很长的内容可以按章节、模块或接口片段拆开比较。

参考资料

• GNU diffutils Manual
• Git diff
• Longest common subsequence