文本对比工具
粘贴两段文本，立即高亮差异行，对标 VS Code 体验
在上方输入两段文本后点击「开始对比」
常见对比示例
点击下方卡片快速加载示例文本，体验差异高亮效果。
这个文本对比工具解决什么问题
代码审查、配置变更、日志排查时，经常需要快速看清两段文本之间到底改了什么。肉眼对比不仅慢，还容易遗漏关键变更。文本对比工具通过 Monaco Editor 的 Diff 引擎，自动高亮每一处新增、删除和修改，让差异一目了然。
支持左右分栏和内联两种视图模式，以及 8 种常用语言语法高亮（JSON、YAML、Python、JavaScript、SQL 等），无论是审查配置文件还是对比代码片段，都能获得接近 VS Code 的阅读体验。
如何使用此工具
将原始文本粘贴到左侧文本框，修改后的文本粘贴到右侧文本框，点击「开始对比」即可触发差异分析。你可以点击中间的交换按钮快速调换两侧内容。
在控件栏可以选择语法高亮语言（JSON、YAML、Python 等 8 种）和视图模式（左右并排或内联模式），切换后差异结果实时更新。
顶部的统计栏会显示新增行数和删除行数，方便快速评估变更规模。注意统计基于行级差异，具体到字符级的修改需要查看编辑器内的高亮。
使用注意事项
- 对比超大文本（>5000 行）时浏览器可能卡顿，建议先缩小范围再对比。Monaco Editor 在移动端性能有限，大文本建议在桌面端处理。
- 行末空格和缩进差异（空格 vs Tab）会被高亮标记，如果发现大量"无意义"差异，请先统一两侧文本的缩进风格。
- 粘贴来自不同系统的文本时注意换行符差异（CRLF vs LF），可能导致整段文本被标记为差异。建议先规范化换行符。
- 所有对比操作都在浏览器本地完成，文本不会上传到服务器。对比敏感配置或密钥时也无需担心泄漏。
典型应用场景
以下是文本对比工具在日常运维开发中的高频使用场景：
对比 PR 中关键文件的改动，快速确认变量重命名、逻辑调整和新增代码。比 GitHub 页面更适合逐行审查长文件。
Nginx、Docker Compose、K8s YAML 等配置上线前，逐项对比新旧版本，避免误改端口、路径或环境变量。
将正常运行的日志与异常日志进行对比，快速定位多出的错误行或缺失的关键步骤。
常见错误模式
文本对比中以下问题高频出现，了解原因和解决方案可以避免误判和返工：
- 换行符不一致导致全量标记
Windows（CRLF \r\n）、Linux/Mac（LF \n）和旧 Mac（CR \r）使用不同的换行符。从不同系统粘贴文本到工具时，若两侧换行符不一致，Monaco Diff 可能将整段文本标记为差异，淹没有意义的改动。解决：对比前先执行换行符规范化——在 VS Code 中可点击右下角行尾序列切换，或使用 dos2unix 命令统一处理。 - 格式化差异淹没真实改动
代码格式化工具（Prettier、Black、gofmt）可能在保存时自动调整缩进或删除行末空格。若一侧文本经过格式化、另一侧未格式化，Diff 结果中空白变更可能占 90% 以上，真正有意义的逻辑改动反而被淹没。推荐做法：对比前对两侧文本统一运行格式化工具，再对比格式化后的结果。 - JSON 键顺序变化误报为大规模修改
不同 JSON 序列化库对对象键的排序策略不同（Python 3.7+ 保持插入序，Go 按字母序，Node.js 按创建序）。两份语义相同的 JSON 因键顺序不同可能被标记为大量差异。对比 JSON 前应先通过 jq --sort-keys 或 json-deep-sort 对键排序，再粘贴到工具中。本工具的 JSON 语法高亮可辅助区分字段值变更和顺序变更。 - 字符编码不统一导致乱码标记
从不同来源（浏览器控制台、curl 输出、日志文件）复制的文本可能使用不同编码（UTF-8、GBK、ISO-8859-1）。中文或特殊字符在编码不匹配时变成乱码，Diff 工具会将乱码标记为差异行。确保两侧文本都使用 UTF-8 粘贴，可通过查看特殊字符（如中文注释、emoji）是否正常显示来快速验证编码一致性。
深度专题：Diff 算法原理与性能考量
理解文本对比工具底层的算法机制，有助于在生产环境中更准确地使用 Diff 功能并规避性能陷阱：
Eugene Myers 在 1986 年提出的 O(ND) 算法（N 为文本长度，D 为编辑距离）至今仍是 git diff、Monaco Editor、VS Code 等主流工具的核心。该算法将最短编辑路径问题转化为编辑图上的最长公共子序列（LCS）求解，找出最小的"删除 + 插入"操作序列将原始文本转换为修改后文本。值得留意的是，算法层面没有"修改"操作——你看到的"修改某行"实际上是"删除原行 + 插入新行"的合并展示，这就是为什么行统计总是按新增/删除来计数。
Monaco Editor（VS Code 的内核）在 Myers 算法之上做了多项工程优化：1）使用 Worker 线程执行计算密集的 Diff 运算，避免阻塞浏览器主线程，这就是为什么本工具加载时需要 editor.worker.js；2）对行级 Diff 进行预处理（哈希行内容以减少比对空间）；3）字符级高亮（inline changes）是在行级匹配完成后对匹配行进行的二次比对，开销显著高于行级 Diff。对于超大文本，本工具已默认关闭 minimap 并启用自动换行以减少渲染压力。
Myers 算法的时间复杂度为 O((M+N)D)，M、N 为两侧行数，D 为最小编辑距离。当两侧文本差异很小时（D → 0），算法接近线性效率。但当文件超过 5000 行且差异较大时，D 急剧增大，计算量呈平方级增长，浏览器可能卡顿。生产环境建议：<500 行直接在线对比毫秒级完成；500-2000 行无明显延迟；>2000 行建议先缩小范围（指定函数/配置段），或改用命令行 git diff 处理。
Monaco Diff 默认先做行级比对（确定哪些行被新增/删除/保留），再对匹配行做字符级比对（高亮行内具体修改的字符）。这就是为什么统计栏显示的是行数统计，而编辑器内还可以看到行内的精细高亮。需要注意：统计栏的计数规则是"左侧独有的行 = 删除行数，右侧独有的行 = 新增行数"，这不同于 git diff --stat 的上下文统计方式，直接用行数判断变更规模可能偏大。
横向对比：合适的场景选合适的 Diff 工具
不同 Diff 工具各有所长。下面是几种主流选项的边界与适用场景，帮你在生产环境快速判断该用哪一个：
纯浏览器运行、零安装，字符级高亮 + 8 种语法着色。适合临时审查别人发来的代码片段、配置变更核对、不想启动 IDE 的快速校对。极限：约 5000 行后开始卡顿，超大文件请走命令行。
版本控制场景的事实标准。--word-diff 给字符级、--algorithm=histogram 给更合理的对齐、--stat 给汇总。适合所有 Git 仓库内的变更审查、生成 patch 文件、CI 流水线集成。纯文本输出，对开发者本人查阅最高效，但分享给非技术同事不够直观。
与本工具底层引擎同源，但增加了「应用本侧改动到对侧」「单行回滚」等可编辑能力。适合合并冲突解决、分支对比、重构后的全文件审查。前提：必须有 IDE 已打开项目，临时片段对比反而启动慢。
三向合并（base/local/remote）、目录树整体对比、二进制对比、Hex 编辑——单一工具内一站式。适合复杂 conflict 合并、对比目录结构、对比二进制资源（图标、字体、镜像层）。代价：商业软件付费 / 跨平台体验不一致 / 团队统一困难。
BSD/GNU coreutils 自带，无依赖。diff -u file1 file2、diff -r dir1 dir2、comm 三件套。适合在服务器上现场对比、shell 脚本中检测差异、生成简单的 unified diff。行级输出，配 colordiff 可着色，但远不如可视化工具直观。