补丁 / diff 检查器
接受一份统一格式 diff——直接粘贴，或者来自 git format-patch、GitHub 的 .patch 链接、邮件列表的 .patch 文件——在你打上它之前告诉你它会做什么。如果补丁带有邮件头，会读出提交标题、作者和日期，然后给出按文件的表格：路径，该文件是新增、删除、修改、重命名、权限变更还是二进制，以及按 git 的计法数出的准确增删行数。核心是回答你真正关心的那个问题：这个补丁能不能干净地打上。统一格式 diff 是自描述的：每个 hunk 头都写明它在两侧各覆盖多少行，形如 @@ -1,4 +1,5 @@，而 git 在动手之前会拿正文去核对这个声明。一旦两者对不上——邮件客户端重新折行了、有人手工改过补丁、或者上下文行开头的那个空格在传输中丢了——git 只会甩出 `corrupt patch at line N`，完全不说它原本期待什么。本工具做同样的算术，把出问题的 hunk、它的头部承诺的数值和正文实际的数值一并摆出来。它还会标出那些更安静的失败：与 LF 文件对不上的 CRLF 换行、会被 pre-commit 钩子拒绝的行尾空白、缺失的文件末尾换行，以及一个 hunk 都没有的文件头。全部在浏览器中运行，补丁不会上传。
| 路径 | 变更 | 新增 | 删除 | 个 hunk |
|---|---|---|---|---|
| src/app.js | 修改 | +2 | −1 | 1 |
| README.md | 新增 | +2 | — | 1 |
使用方法
- 把统一格式 diff 粘贴到输入框，或者把 .patch、.diff 文件拖进去。
- 看合计了解改动规模：文件数、新增行、删除行和 hunk 数量。
- 在表格里找你关心的文件；重命名的文件会在新路径旁显示旧路径。
- 运行 git apply 之前先看琥珀色高亮的条目——那就是它会失败的原因。
- 如果补丁来自邮件，把 hunk 警告和 `git apply --check` 的结果对照看，后者报告同样的损坏但更简略。
常见问题
- `corrupt patch at line N` 到底是什么意思？
- 意思是 hunk 的正文没有包含它头部声明的行数。像 @@ -1,4 +1,5 @@ 这样的头部承诺旧侧四行（上下文加删除）、新侧五行（上下文加新增）。git 边读边数，一旦算术对不上就立刻停下，报告的是它读到的那一行，而不是那个写错了的头部。原因几乎总是传输：邮件客户端把长行折了，或者把标记上下文行的那个开头空格删了，于是有一侧少了。本工具会指出是哪个 hunk、承诺了多少、实际是多少，通常这就够你手工修好了。
- 空的上下文行为什么那么容易毁掉补丁？
- 因为上下文行是靠开头一个空格来标记的，所以一个没有改动的空行最终就是「只有一个空格的行」。它看不见，而大量工具会把它剪掉：保存时清除行尾空白的编辑器、邮件客户端、聊天软件、经过终端的复制粘贴。空格一没，这行就被当成空行而不是上下文，hunk 两侧就都少了一行。这是一个在屏幕上看着没毛病的补丁打不上去的最常见途径。
- 这个工具会应用补丁，或者拿它跟我的文件比对吗？
- 不会，也做不到。它读的是补丁本身——diff 内部的算术——完全不接触补丁指向的文件。这已经足以抓出损坏或被弄坏的补丁，因为那只是补丁自身的性质。但它无法判断上下文行是否与你的工作树一致，所以本工具认为格式正常的补丁，若文件已经往前走了，仍然可能以 `does not apply` 被拒。那种检查需要文件，命令是 `git apply --check`。
- 除了 git 补丁，它能读普通的 `diff -u` 输出吗？
- 能。git 补丁多了 `diff --git` 行、index 行、重命名与权限的元数据，如果是 format-patch 还会有邮件头，这些只要存在都会被读取。diff -u 产生的普通统一格式 diff 没有这些，直接以 `--- ` / `+++ ` 头部对开头，处理方式相同。只是重命名和权限变更在普通格式下根本无法识别，因为这个格式没有表达它们的手段。
- 这里的行数为什么和 GitHub 显示的不一样？
- GitHub 的文件视图数的是同样的行，但它的汇总有时不同，因为它会隐藏生成的文件、折叠大 diff，并把二进制文件排除在合计之外。本工具数的是你给它的补丁里的每一个 hunk，这个数字与 `git apply --numstat` 报告的一致。如果合计对不上，先确认手上的补丁是不是完整的改动——单个提交的 .patch 链接不会等于一个 pull request 的累积 diff。
- 我的补丁会被上传吗？
- 不会。文本由本页面的 JavaScript 解析，不会发送到任何地方；拖进来的文件也一样，用浏览器自带的文件 API 读取。你可以打开页面后断开网络再粘贴一份 diff 来验证，它照常工作。这一点值得留意，因为补丁往往是评审过程中最敏感的东西：它完整地装着尚未发布的代码。
相关工具
JSON Patch 构建器 (RFC 6902)
从 source/target 对生成 RFC 6902 JSON Patch，或将现有 patch 应用到文档。支持 add、remove、replace、move、copy、test 操作。
文本 Diff 查看器
比较两段文本，按行或按词高亮显示新增与删除。
.gitignore 测试器
粘贴 .gitignore 和一组路径，立刻看出哪些被忽略，以及究竟是哪一行做的决定，与 git check-ignore -v 的答案一致。
Semver 工具（解析、比较、版本号递增）
并排解析、比较和递增语义化版本号，附范围展开器，告诉你 ^x.y.z 和 ~x.y.z 实际覆盖到哪。
Conventional Commit 提交信息生成器
在浏览器中生成包含类型、范围、破坏性变更和脚注的 Conventional Commits 提交信息。
.gitignore 生成器
勾选你使用的语言、框架、编辑器和操作系统 — 得到一个可直接放进新仓库的整合 `.gitignore`。