OmniDiff 是一款开源文件对比工具，除了代码和普通文本，还能比较图片、PDF、字体、压缩包等文件。它会根据不同内容选择对应的 Diff 方式，例如代码按语法结构分析，图片比较像素变化，PDF 按页面检查，压缩包则可以继续查看内部文件。
目前 OmniDiff 支持 25 种通过 Tree-sitter 解析的代码和结构化文本类型，并可接入 Git、Jujutsu、VS Code 和 Neovim。相比普通 git diff，OmniDiff 遇到 PDF、图片、字体这类文件时，不只是显示一句 Binary files differ，还会继续分析文件内部到底发生了什么变化。
项目 Showcase： OmniDiff Showcase
GitHub： ivankovic/omnidiff
OmniDiff 是什么样的文件对比工具？
OmniDiff 的核心是 content-aware diffing，也就是先判断文件内容，再选择更合适的比较方式，而不是什么文件都按文本行处理。
官方展示过一个 Python 重构案例：GNU Diff 会把发生变化的整行标成删除和新增；OmniDiff 则会进一步识别真正修改的表达式，以及哪些代码只是移动了位置。遇到函数重构、代码块调整这类改动时，更容易看出真正改了什么，而不是被大段删除和新增淹没。
代码和结构化文本部分目前使用 Tree-sitter 解析 25 种类型，常见的 Python、JavaScript、TypeScript、Rust、Go、Java、PHP、Swift、C/C++ 都在其中，同时也包括 JSON、YAML、XML 这类项目里经常出现的数据和配置格式。
严格来说，官方所说的 25 种并不全是“编程语言”。JSON、YAML、XML 更接近数据和配置格式。对开发者来说，这反而更实用，因为一个项目里真正需要检查的往往不只是源码，配置文件同样经常随着提交一起变化。
不是所有文本格式都会做结构化 Diff
OmniDiff 对不同格式的支持程度并不完全一样。
Python、Rust、JSON、YAML 等有对应解析器的格式，会经过 Tree-sitter 做结构化比较；Markdown、SQL、Dart、Protocol Buffers 等虽然可以识别，目前仍然按照普通文本逐行比较。
像 TOML、INI 这类没有列入结构化解析列表的文本文件，也不会因此无法比较，而是退回普通的逐行文本 Diff。
二进制文件也是类似的逻辑。图片、PDF、字体、压缩包等已经有专门的内容级处理方式；其他暂未支持的二进制文件，才会退回普通的二进制差异提示。
所以判断 OmniDiff 是否“支持”某种文件时，不能只看扩展名，更重要的是看它能把这个格式理解到什么程度。
OmniDiff 支持哪些文件类型？
| 内容类型 | 比较方式 | 适合场景 |
|---|---|---|
| 代码 | Tree-sitter 语法结构 Diff | 代码审查、重构、Git 提交 |
| JSON / YAML / XML | 按结构解析，而不只是逐行比较 | 配置文件、项目配置变化 |
| 图片 | 逐像素检查变化位置，动画逐帧比较 | UI 资源、设计稿、图片版本 |
| 逐页绘制并检查页面变化 | 技术文档、图表、导出结果 | |
| ZIP / TAR 等压缩包 | 展开并逐项比较，支持嵌套归档 | Release 包、构建产物 |
| Office / JAR / EPUB | 利用 ZIP 容器结构继续检查内部内容 | 检查文件内部组成变化 |
| 字体 | 比较 Glyph、名称和 Metrics | Web Font、Icon Font |
| 光标 | 按尺寸和动画帧比较 | Windows / X Cursor 资源 |
| .mo / .qm | 逐条 Message 比较 | 软件翻译文件更新 |
OmniDiff 实际能看到哪些文件变化？
OmniDiff 的 Showcase 里放了几组真实文件的 Diff 结果，包括 PDF、字体、图片和 OpenDocument。下面的数据都来自这些录制示例，不是本站独立测试。
PDF：可以定位到具体页面和变化区域
其中一个 PDF 只改了图表里的一个名称。OmniDiff 不只是判断两个文件不同，还会继续标出元数据和页面变化；这个案例里，第 1 页大约只有 0.21% 的像素发生变化，并被定位到一个区域。
对于自动生成的技术文档、报表、架构图或者 Release 附带的 PDF，这种结果比单纯看到文件发生变化更有用。
不过它仍然不是 Adobe Acrobat 一类专业 PDF 审阅工具，而且目前 PDF 的人工评估样本还比较少，因此更适合作为开发工作流里的补充能力。
字体：能看到具体哪些 Glyph 被改了
TrueType、OpenType、WOFF、WOFF2 和 EOT 都可以进一步拆开比较，包括字体名称、Metrics 和具体 Glyph。
Font Awesome 的一个 WOFF2 案例里，1996 个成员中有 21 个发生变化，OmniDiff 可以直接把这些字形列出来，并显示修改前后的效果。
如果项目使用 Icon Font 或自己维护 Web Font，这比只知道两版字体文件 Hash 不同直观得多。
图片：不只是判断文件不同
PNG、JPEG、GIF、WebP、BMP、ICO 和 TIFF 都有对应的图片比较方式。静态图片可以定位像素变化区域，动画则会继续比较帧。
一个 BMP 案例中，178176 个像素里只有 73 个变化，OmniDiff 可以把范围缩小到一个很小的区域。另一个 ICO 从 16×16 调整到 32×32，会直接识别为尺寸变化；GIF 从 5 帧变成 7 帧时，也能看到新增的是哪两帧。
压缩包：还能继续往里面比较
ZIP、TAR、gzip、xz、bzip2 这类归档文件不会只停留在压缩包本身。OmniDiff 会展开里面的成员，再根据每个文件自己的类型继续比较，嵌套归档也可以继续处理。
因此 JAR、EPUB，以及基于 ZIP 容器的 Office、OpenDocument 文件也能看到内部变化。一个 ODT 案例里，content.xml、meta.xml、样式文件和缩略图的变化都可以分别列出来。
OmniDiff 可以用来比较 Word 和 Excel 吗？
可以检查基于 ZIP 容器的 Office 文件内部发生了哪些变化，但这里需要特别区分：
OmniDiff 不等于 Word 的“比较文档”，也不等于 Excel 单元格级差异分析工具。
它更关注文件内部结构和成员变化，而不是专门理解 Word 修订语义或把 Excel 不同单元格直接高亮出来。
如果你的主要需求就是比较两个 Excel 文件、快速定位不同单元格，可以看我们之前介绍的 Diff Excel。OmniDiff 更适合源码、配置、图片、字体、文档和构建产物混在一起的开发项目。
OmniDiff 怎么安装？
截至 2026 年 11 月，OmniDiff 最新正式版本为 v0.3.0，官方提供 Linux、Windows、Intel Mac 和 Apple Silicon Mac 的预编译程序。
macOS 和 Linux：Homebrew
brew install ivankovic/omnidiff/omnidiff通过 Cargo 安装
cargo install --locked omnidiff源码安装需要 C 编译器以及 Rust 1.92 或更高版本。因为安装过程会编译 Tree-sitter Grammar，第一次通过 Cargo 安装会比直接下载预编译程序慢一些。
Debian / Ubuntu
项目还提供 amd64 和 arm64 的签名 APT 软件源，长期在 Debian 或 Ubuntu 开发环境中使用时，不一定需要自己维护二进制文件。
Nix 用户也可以直接运行：
nix run github:ivankovic/omnidiffOmniDiff 怎么使用？
最基本的方式就是给它两个文件：
omnidiff BEFORE AFTER会打开 OmniDiff 的双栏终端界面。
如果用于自动化脚本或 CI，可以切换 Headless 模式：
omnidiff --headless BEFORE AFTER或者直接输出 JSON：
omnidiff --mode json BEFORE AFTER如果需要让“存在差异”反映到脚本退出状态中，还可以配合 --exit-code 使用。
因此 OmniDiff 不只可以作为 Diff Viewer，也可以接进 CI、检查脚本和其他自动化流程。
怎么把 OmniDiff 接进 Git？
OmniDiff 可以作为 Git difftool 使用。
运行：
omnidiff git configure完成配置后，可以通过：
git difftool --tool=omnidiff打开完整的交互式终端界面。
这里需要注意 git difftool 和普通 git diff 的区别。
git difftool 可以让 OmniDiff 使用完整 TUI；普通 git diff 和 git log -p 通常运行在 Pager 中，没有完整交互式终端环境，因此 OmniDiff 会自动改成非交互文本输出。
如果执行普通 git diff 后没有出现双栏界面，并不代表配置失败。
Jujutsu（jj）也可以用，但要注意 file-by-file
OmniDiff 同样提供 Jujutsu 配置向导：
omnidiff jj configurejj 默认会把两个目录树交给外部 Diff 工具，而 OmniDiff 比较的是两个文件，因此必须使用 file-by-file 调用模式。
diff-invocation-mode = "file-by-file"普通 jj diff 同样通过 Pager 输出，因此会使用 OmniDiff 的非交互文本模式。如果想看完整 TUI，目前仍然需要直接运行 omnidiff BEFORE AFTER。
VS Code、Cursor 和 Windsurf 能用吗？
OmniDiff 有 VS Code 扩展，Open VSX 版本也可以安装到 VSCodium、Cursor 和 Windsurf 等兼容编辑器。
不过目前还有一个平台限制：VS Code 现阶段还不能让第三方扩展完整替换编辑器内置的 Diff View。
相关 API 已经在上游实现，但尚未正式发布。因此现阶段如果想体验 OmniDiff 完整能力，Git difftool 和独立终端 TUI 仍然更直接。
OmniDiff 官方演示页能直接在线比较文件吗？
不能。OmniDiff 的 Showcase 是官方演示页，主要用来查看已经录制好的代码、PDF、字体和图片 Diff 效果，并不提供上传文件在线比较的功能。
要比较自己的文件，还是需要在本地安装 OmniDiff。对于源码、内部文档这类不方便上传到第三方网站的内容，本地处理会更合适。
OmniDiff 的性能怎么样？
项目作者公开了自己的性能和准确率测试。代码部分目前有 2302 个测试样本，在 Intel Core i7-1370P、32GB RAM 的 ThinkPad T14s 上，中位数约为 4.2ms，p90 为 35.1ms，p99 为 177ms，约 97.6% 的样本可以在 100ms 内完成。
| 内容类型 | 100ms 内完成 | Perfect | Near-perfect |
|---|---|---|---|
| 代码 | 98% | 70% | 92% |
| 图片 | 96% | 69% | 91% |
| 光标 | 100% | 85% | 100% |
| 字体 | 95% | 82% | 100% |
| 压缩包 | 88% | 87% | 87% |
| Message Catalog | 100% | 83% | 83% |
| 57% | 100% | 100% |
从这些数据看，代码、图片和字体的速度已经比较稳定，PDF 会明显慢一些，因为需要把发生变化的页面实际绘制出来；包含大量成员的压缩包同样可能拉长处理时间。
PDF 那组“100%”准确率也不能单独拿出来看。项目也说了，经过人工判断的 PDF 样本不足 10 个，因此目前还不足以说明 PDF Diff 已经和代码一样成熟。
另外，这些都是项目作者自己的测试结果，并不是本站独立 Benchmark。比较重要的代码或发布文件，最终还是应该由人确认 Diff 是否合理。
OmniDiff 目前还有哪些不足？
OmniDiff 现在明显还是一款偏开发者和终端工作流的工具。主要界面是 CLI 和 TUI，没有 Beyond Compare 那种成熟桌面 GUI，也不主打目录同步、三方 Merge 和冲突编辑。如果这些功能是日常刚需，现有工具未必需要换掉。
格式支持也不是一个水平。Python、Rust、JSON、YAML 等可以做结构化 Diff，Markdown、SQL、Dart、Protocol Buffers 目前仍然只是普通文本比较；Office 文件虽然可以继续检查 ZIP 容器内部变化，但不能代替 Word 修订审阅或 Excel 单元格差异工具。
PDF、字体、图片这些非代码格式已经能做内容级比较，不过成熟度并不完全一致，前面的测试数据也能看出这种差异。
编辑器集成同样还有限制。VS Code 扩展目前不能完整替换内置 Diff View，所以现阶段要体验 OmniDiff 的完整效果，终端 TUI 和 Git difftool 还是更直接。
OmniDiff 的许可证要注意什么？
OmniDiff 使用 AGPL-3.0-only 开源，并不是 MIT、Apache-2.0 这类限制较少的许可证。
对个人开发者来说，按 AGPL 条款使用即可；如果公司准备把 OmniDiff 长期放进内部工具链，又不适合采用 AGPL，项目作者还提供单独的商业授权。
所以企业使用前最好顺手确认一下许可证要求，尤其是涉及修改、部署或分发时。
OmniDiff 适合什么场景？
如果平时主要使用 Git、Jujutsu 或终端，而且项目里除了源码，还经常出现图片、字体、PDF、翻译文件和构建产物，OmniDiff 会比较实用。代码审查、大型重构、Release 前检查，以及在 CI 中输出结构化 Diff，都是比较合适的场景。
如果只是偶尔比较两段普通文字，在线文本 Diff 工具会更省事；主要比较 Excel，则专用 Excel Diff 更直接；如果依赖目录同步、三方 Merge 和完整桌面 GUI，Beyond Compare 这类成熟工具仍然更合适。
常见问题
OmniDiff 支持 Windows、macOS 和 Linux 吗？
支持。官方提供 Windows、Linux、Intel Mac 和 Apple Silicon Mac 的预编译版本。macOS 和 Linux 可以使用 Homebrew，Debian / Ubuntu 也有官方提供的 APT 软件源。
OmniDiff 可以比较 Word 和 Excel 吗？
可以检查基于 ZIP 容器的 Office 文件内部成员变化，但它不是 Word 文档审阅工具，也不是 Excel 单元格差异分析软件。
OmniDiff 可以替代 git diff 吗？
更准确地说，它适合作为 Git 的外部 Diff 工具补充现有工作流。完整 TUI 通常通过 git difftool 使用，而普通 git diff 在 Pager 中会显示非交互文本结果。
OmniDiff 免费吗？商用有什么限制？
源代码按照 AGPL-3.0-only 许可证提供。无法采用 AGPL 条款的组织，可以查看作者提供的商业许可证方案。企业正式采用前建议核对项目当前许可原文。
OmniDiff 值得用吗？
如果平时只比较代码或普通文本，现有的 Git Diff 已经够用，没必要专门换工具。OmniDiff 更适合项目里经常混着图片、PDF、字体、配置文件和打包产物的情况，至少遇到这些文件时，不会只停在“文件发生了变化”。
它现在还是明显偏终端和 Git 工作流，GUI、Merge 和 Office 专业审阅都不是强项。但如果你经常做代码审查、Release 检查，或者想知道二进制文件具体改了什么，可以装下来试试。
官方演示页： OmniDiff Showcase
GitHub： ivankovic/omnidiff
评论(0)